[GHC] #14707: setNumCapabilities can cause threads to get stuck in gcWorkerThread

[GHC]

#14707: setNumCapabilities can cause threads to get stuck in gcWorkerThread
-------------------------------------+-------------------------------------
           Reporter:  duog           |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Runtime        |           Version:  8.5
  System                             |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 I have a patch with some instrumentation that proves that sometimes
 threads do not leave gcWorkerThread until the following gc.

 I suspect it's caused by `idle_caps` being mutated in `scheduleDoGC` after
 the call to `requestSync`. A thread enters `yieldCapability` sees that
 itself is not idle, so enters `gcWorkerThread`, but then `idle_caps` is
 mutated so that that thread *is* idle, and it's spin locks are not touched
 by the garbage collector.

 Potential fixes:
 * Don't look at `idle_caps` in the garbage collector when we're touching
 the spin-locks, just do it for all capabilities. I don't *think* this does
 any harm.
 * Don't mutate `idle_caps` after the call to `requestSync`; move that
 logic to before the call.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14707>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler