diff options
| author | simonmar <unknown> | 2002-12-03 14:30:12 +0000 |
|---|---|---|
| committer | simonmar <unknown> | 2002-12-03 14:30:12 +0000 |
| commit | 0f9d7cc2a45bb05fbc751f0f2545e5cc41dc9627 (patch) | |
| tree | 6a1ec4f6aa56f13f7009cbc3e7832af6b47b7733 /libraries/base/Control/Concurrent/QSemN.hs | |
| parent | 2d187577b644d227ace6fba319adb77627230432 (diff) | |
| download | haskell-0f9d7cc2a45bb05fbc751f0f2545e5cc41dc9627.tar.gz | |
[project @ 2002-12-03 14:30:12 by simonmar]
Eeek! A nasty bug has been lurking in waitQSemN, which as far as I
can make out has been there for ever. Presumably no-one uses this
abstraction...
The bug is that waitQSemN would discard any other blocked threads
(presumably waiting for a larger chunk of the semaphore) if it
succeeds.
It still looks to me like the quantity semaphores in here can suffer
from starvation: if one thread requests a large chunk, while lots of
other threads are requesting smaller chunks, then the thread
requesting the large chunk might never get to run. I'm sure this must
be a well-known problem.
MERGE TO STABLE
Diffstat (limited to 'libraries/base/Control/Concurrent/QSemN.hs')
| -rw-r--r-- | libraries/base/Control/Concurrent/QSemN.hs | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/libraries/base/Control/Concurrent/QSemN.hs b/libraries/base/Control/Concurrent/QSemN.hs index 8e95903ea8..d8d6f49b9f 100644 --- a/libraries/base/Control/Concurrent/QSemN.hs +++ b/libraries/base/Control/Concurrent/QSemN.hs @@ -42,7 +42,7 @@ waitQSemN (QSemN sem) sz = do if (avail - sz) >= 0 then -- discharging 'sz' still leaves the semaphore -- in an 'unblocked' state. - putMVar sem (avail-sz,[]) + putMVar sem (avail-sz,blocked) else do block <- newEmptyMVar putMVar sem (avail, blocked++[(sz,block)]) |