Changes between Version 109 and Version 110 of LightweightConcurrency


Ignore:
Timestamp:
May 23, 2012 5:38:31 PM (2 years ago)
Author:
kc
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • LightweightConcurrency

    v109 v110  
    367367=== Black-hole Handling === 
    368368 
    369 Any thunk evaluation may encounter a blackhole - a thunk under evaluation. When a thread encounters a thunk, the vanilla GHC suspends the thread until the thunk finishes evaluation. Similar to the solutions developed above, we can utilize the scheduler actions to yield control to another thread from the user-level scheduler. However, since the scheduler actions themselves are implemented in Haskell code, which can encounter blackholes, we might encounter situations where the user-level scheduler becomes blocked on a thread that it is scheduling, resulting in a deadlock. Moreover, the thread evaluating the blackholed thunk (blackhole owner) might be running on the same or a different capability as the thread entering the blackhole. This complicates the problem of potentially resuming a blackholed thunk's evaluation. In addition to all of these concerns, we would like the common case - a thunk finishing evaluation without being blackholed - to be fast. 
     369Any thunk evaluation may encounter a blackhole - a thunk under evaluation. When a thread encounters a thunk, the vanilla GHC suspends the thread until the thunk finishes evaluation. Similar to the solutions developed above, can utilize the scheduler actions to yield control to another thread from the user-level scheduler? Since the scheduler actions themselves are implemented in Haskell code, they can encounter blackholes. We might encounter situations where the user-level scheduler becomes blocked on a thread that it is scheduling, resulting in a deadlock.  
     370 
     371Since thunks (usually) represent pure computation, can we not duplicate thunk evaluation when we detect a deadlocked scheduler? Unfortunately, this is not so straightforward. The closure that represented the thunk is lost when it was black-holed. Moreover, the thread evaluating the blackholed thunk (blackhole owner) might be running on the same or a different capability than the thread entering the blackhole. Correspondingly, the blackhole owner thread might either not be schedulable or running. This complicates the problem of potentially forcing a blackholed thunk's evaluation on a thread other than the blackhole owner. In addition to all of these concerns, we would like the common case - a thunk finishing evaluation without being blackholed - to be fast. 
    370372 
    371373When a thread enters a blackhole, there are essentially 3 parameters that we need to consider: