Hi Andreas,<br><br>ok, I didn't explain it thorough enough. That's why meeting can be nice sometimes!<br><br>I'm keeping my two statements up.<br><br>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.
<br><br>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...'
<br>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:
<br><br>Semaphore>>wait<br>"...<br>The calling process is required to check if it was signaled by some external means as the signaling might occur bogusly."<br>...<br><br>Isn't this the consequence of the possible double signaling?
<br><br>Cheers,<br>Georg<br><br><div class="gmail_quote">On Jan 5, 2008 4:28 PM, Andreas Raab <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Georg Köster wrote:<br>> The second implementation has clearly other troubles (I didn't see that<br>> it's just using a LinkedList that's apparently not thread safe), but I<br>> explained before that I believe at least the double signaling is dealt
<br>> with.<br><br></div>It most definitely does not prevent double signaling! What makes you<br>think it does? It is easiest to see in the case where we first get a<br>timeout signal, and then -while being inside #resumeProcess:- the "real"
<br>event. Obviously there is nothing in the implementation that prevents<br>the second signal from occurring.<br><div class="Ih2E3d"><br>> I would recommend at least adding this problem to the documentation of<br>> wait*, that if one of the timed waits is used the wait (without timeout)
<br>> contract is violated in that it might return even if no user process<br>> sent a signal.<br><br></div>Well, duh. It is the very *definition* of waitTimeoutMSecs: that it may<br>return although the event hasn't occurred. That's what the method does.
<br>The comment is explicit, too noting that "It is up to the sender to<br><div class="Ih2E3d">determine the difference between the expected event and a timeout".<br><br></div>Cheers,<br><font color="#888888"> - Andreas
<br><br></font></blockquote></div><br>