Hi Andreas,

ok, I didn't explain it thorough enough. That's why meeting can be nice
sometimes!

I'm keeping my two statements up.

To the first: The doubled signal and its resume would occur, but it would
resume a process that is already resumed, and therefore have no effect (I
assume that the process doesn't skip a wait because of a resume received
while running). The process can only be waiting again and therefore
vulnerable to a doubled signal if he passes the termination of the
interrupting thread - and past this termination no signaling from the dead
process can occur. So yes, double signaling may occur - but it's dealt with.

To the second: Yes, definition of waitTimeoutMSecs:, but not wait:! That's
what I meant when I said 'if one of the timed waits [waitTimeoutMSecs or
-Seconds] is used the wait (without timeout) contract is violated...'
It is very normal that the caller needs to check the result after using a
timed wait, but nothing in the doc states that also the processes calling a
forever-blocking wait will now need to check the result. That should be
added. Something along the lines of:

Semaphore>>wait
"...
The calling process is required to check if it was signaled by some external
means as the signaling might occur bogusly."
...

Isn't this the consequence of the possible double signaling?

Cheers,
Georg

On Jan 5, 2008 4:28 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Georg Köster wrote:
> > The second implementation has clearly other troubles (I didn't see that
> > it's just using a LinkedList that's apparently not thread safe), but I
> > explained before that I believe at least the double signaling is dealt
> > with.
>
> It most definitely does not prevent double signaling! What makes you
> think it does? It is easiest to see in the case where we first get a
> timeout signal, and then -while being inside #resumeProcess:- the "real"
> event. Obviously there is nothing in the implementation that prevents
> the second signal from occurring.
>
> > I would recommend at least adding this problem to the documentation of
> > wait*, that if one of the timed waits is used the wait (without timeout)
> > contract is violated in that it might return even if no user process
> > sent a signal.
>
> Well, duh. It is the very *definition* of waitTimeoutMSecs: that it may
> return although the event hasn't occurred. That's what the method does.
> The comment is explicit, too noting that  "It is up to the sender to
> determine the difference between the expected event and a timeout".
>
> Cheers,
>   - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080105/50441a64/attachment.htm