[GHC] #15194: Consider a QSem variant that can hold back resources

[GHC]

#15194: Consider a QSem variant that can hold back resources
-------------------------------------+-------------------------------------
           Reporter:  dfeuer         |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:  8.6.1
          Component:  Core           |           Version:  8.2.2
  Libraries                          |
           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:
-------------------------------------+-------------------------------------
 `QSem` always wakes up threads when resources become available. This leads
 to unavoidable contention between waiting and signaling threads. If,
 however, a quantity semaphore is allowed to hold some resources back, then
 these can be decoupled.

 One `MVar` holds an immediately available resource quantity or a list of
 threads waiting to be enqueued. The other holds a reserved resource
 quantity or a FIFO queue of threads. The only non-exceptional time an
 operation needs both `MVar`s is when signaling exceeds the reserve
 capacity. In that case, the reserve is dumped into the available bucket,
 listed threads are enqueued, and threads in the queue are woken up until
 resources or threads are exhausted.

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