I haven't run the program, but are you sure (5) happens? It is fine for task 0 to hit your ASSERT even when setNumCapabilities is running, because it still needs to check whether or not it's acceptable to run, and that won't happen until setNumCapabilities. What it seems to me is happening is
#8209: Race condition in setNumCapabilities -------------------------------------+---------------------------------- Reporter: akio | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by akio): Replying to [comment:2 ezyang]: that waitForReturnCapability is improperly pre-committing to the capability it wants to return to, whereas it should always retrieve a fresh candidate capability each time around the wait loop. Yes, it seems that that is what's happening in practice. However, isn't there still a possibility that e.g. task 0 tries to acquire {{{cap->lock}}} in {{{waitForReturnCapability}}}, after {{{cap}}} is {{{stgFree}}}d in {{{setNumCapabilities}}}? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8209#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler