Consider a QSem variant that can hold back resources
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 MVars 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.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |