Hi Andreas, all,<br><br>first of all: Sorry, it also works in my fresh Croquet image. The backup I always used is apparently not as fresh as I thought :-( mince. And I didn't see that email :-( Double sorry.<br><br>Newbie qestion: Why are images restartable? Why not label them differently (for example as 'core dump') if they don't work?
<br><br>To the race discussion. I think we have a point:<br> § double signaling is unavoidable if a critical section is to be avoided<br><br>Therefore there is a race in the first implementation.<br><br>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.
<br><br>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.
<br><br>Best regards and thanks for considering my comments in the first place!<br>Georg<br><br><div class="gmail_quote">On Jan 5, 2008 3:05 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>> Hey I prefer Tom's version! I shouldn't be racy if I read the
<br>> resumeProcess and resume code correctly. The resumeProcess message has<br>> no effect on non-waiting processes!<br><br></div>To the contrary. This code *introduces* a race condition when<br>manipulating the Semaphore's list of processes without protecting it
<br>against concurrent modifications. Worse, the code *cannot be protected*<br>against concurrent modification since the VM manipulates that list on<br>its own. It may actually explain why some people have reported issues on
<br>3.9 that do not seem to appear on 3.8 or 3.10 variants.<br><div class="Ih2E3d"><br>><br>> > | waitingProcess wakeupProcess |<br>> > waitingProcess _ Processor activeProcess.
<br>> > wakeupProcess _<br>> > [(Delay forMilliseconds: (anInteger max: 0)) wait.<br>> > self resumeProcess: waitingProcess] fork.<br>> >
<br>> > self wait.<br>> "preempting here and getting the resumeProcess message sent would<br>> have no effect - therefore no race!"<br><br></div>What are you talking about? With the original code there was no race
<br>condition whatsoever. If you think there is a race condition somewhere,<br>please explain in detail where you think that race condition is.<br><div class="Ih2E3d"><br>> "in comparison having a semaphore getting signaled here would cause
<br>> an excess signal on the sem: bad"<br><br></div>First, the original code was guarded with a call to #unschedule which<br>would avoid a second signal if the "real event" occurs long enough<br>before the "timeout event". On the other hand, neither implementation
<br>prevents a double-signal if the real event occurs within an epsilon of<br>the timeout event. And due to the asynchronous nature of some semaphore<br>signals it is impossible to have a light-weight implementation like the
<br>one provided in Semaphore handle this correctly. It's possible to<br>handle this but this would require to separate the semaphore and the<br>delay signal and use a critical section to decide which one came first<br>
and how to deal with the other. That, on the other hand, seems overkill<br>for the 99% of the cases in which the simplistic implementation in<br>3.8/3.10 is all that's needed.<br><br>Cheers,<br><font color="#888888"> - Andreas
<br><br><br><br><br></font></blockquote></div><br>