Changes between Version 75 and Version 76 of LightweightConcurrency


Ignore:
Timestamp:
May 22, 2012 6:32:04 PM (2 years ago)
Author:
kc
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • LightweightConcurrency

    v75 v76  
    334334We retain certain components of GHC's concurrency support that interact with the scheduler in the C part of the runtime system (RTS). Some of these interactions such as non-termination detection and finalizers become clear only in the RTS. Other interactions like safe-foreign calls and asynchronous exceptions, which can potentially be implemented in Haskell, are retained in the RTS for performance and simplicity. Furthermore, there are issues like [#Black-holeHandling black-holes], which are complicated enough that they are best handled transparently from the programmer's point of view. 
    335335 
    336 We observe that our [#AbstractingtheScheduler scheduler actions] are sufficient to capture the interaction of user-level scheduler and RTS. As mentioned earlier, the scheduler actions are saved as fields in the TSO structure. In order to invoke the scheduler actions from the RTS (''upcalls''), we need a container thread. We associate with every capability an ''upcall thread'' and an ''upcall queue''. Whenever a scheduler action needs to be invoked from the RTS, the scheduler action is added to the upcall queue. During every iteration of the RTS `schedule()` loop, we check for pending upcalls. If there are pending upcalls, we save the current thread, switch to the upcall thread, execute every upcall to completion, and finally switch to the original thread. 
     336We observe that our [#AbstractingtheScheduler scheduler actions] are sufficient to capture the interaction of user-level scheduler and RTS. As mentioned earlier, the scheduler actions are saved as fields in the TSO structure. In order to invoke the scheduler actions from the RTS (''upcalls''), we need a container thread. We associate with every capability an ''upcall thread'' and an ''upcall queue''.  
     337 
     338Whenever a scheduler action needs to be invoked from the RTS, the scheduler action is added to the upcall queue. During every iteration of the RTS `schedule()` loop, we check for pending upcalls. If there are pending upcalls, we save the current thread, switch to the upcall thread, execute every upcall to completion, and finally switch to the original thread. 
     339 
     340Next, we shall look at various RTS interaction with the user-level scheduler and how scheduler actions enable them. 
     341 
     342=== Blocked Indefinitely === 
     343 
     344 
    337345 
    338346== Related Work ==