[project @ 2002-12-03 14:30:12 by simonmar]
authorsimonmar <unknown>
Tue, 3 Dec 2002 14:30:12 +0000 (14:30 +0000)
committersimonmar <unknown>
Tue, 3 Dec 2002 14:30:12 +0000 (14:30 +0000)
commitc02cf39e4519f85d048bd5f0608de576eab9cabe
tree2fdac545bafa945988be61d9a35754028dc256e6
parent280ab1d20ac18603ace6b1c62b5e83a6d6200e75
[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
Control/Concurrent/QSemN.hs