#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