I resend this one also because this is important to have basic 
concurrent abstraction
right in Squeak.
Can a concurrent guy really have a look at it?

Stef

Begin forwarded message:

> From: Nathanael Schärli <n.schaerli at gmx.net>
> Date: Tue Jun 18, 2002  11:17:53 AM Europe/Zurich
> To: squeak-dev at lists.squeakfoundation.org
> Subject: [BUG][FIX] SharedQueue flushing
> Reply-To: squeak-dev at lists.squeakfoundation.org
>
> Hey
>
> I have noticed that there are bugs in the methods SharedQueue>>flush 
> and
> SharedQueue>>flushAllSuchThat:. The problem is that both of them do not
> properly adjust the semaphore "readSynch" which is used to block 
> readers
> if the queue is empty. Look at the following examples:
>
> q _ SharedQueue new.
> q nextPut: 100.
> q flush.
> q next.
>
> This example should block the active process because there is currently
> no element in the queue. Instead, you get an error message ("Error in
> SharedQueue synchronization").
>
> q _ SharedQueue new.
> q nextPut: 100.
> q nextPut: 200.
> q flushAllSuchThat: [:each | each > 150].
> q next.
> q next.
>
> Also this example should block the active process because there is
> currently no element in the queue. Instead, you get the same error
> message ("Error in SharedQueue synchronization").
>
>
> I have attached a little changeset that fixes this problem.
>
> Cheers,
> Nathanael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FixSharedQueue.1.cs
Type: application/octet-stream
Size: 1262 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030706/d68ee3cc/FixSharedQueue.1.obj