"Lex Spoon" <lex at cc.gatech.edu> wrote:
[SNIP]
> #nextOrNil is pretty good.  It checks whether something is there, and it
> removes it for you if there is.  It avoids race conditions and it's
> really simple to reason about.  If it returns nil, then #isEmpty was
> true.  If something is there, then you've got it with no further
> question.

But as I wrote (if you read my earlier posting in this pretty long
thread) it too has a problem.
It doesn't wait on the readSemaphore which means it can go "straight by"
x other Processes waiting on the readSemaphore (or sitting inbetween the
readSemaphore and the critical: - yes, that is also possible - sigh).

And since the reading critical: block (in #next) don't take into account
that the queue can be empty - since the logic of the class is that the
signal count on the readSemaphore should match the number of objects in
the queue - it will then end up with a:

self error: 'Error in SharedQueue synchronization'.

Soo... no, it's not that good IMHO! ;-) :-)

regards, Göran

> Lex

PS. This thread talks about plenty of problems and solutions to the
SharedQueue class. Someone (perhaps me being a harvester) should sit
down and try to rewrite it so that it actually works. DS