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&#39;t see that email :-( Double sorry.<br><br>Newbie qestion: Why are images restartable? Why not label them differently (for example as &#39;core dump&#39;) if they don&#39;t work?
<br><br>To the race discussion. I think we have a point:<br>&nbsp;§ 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&#39;t see that it&#39;s just using a LinkedList that&#39;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 &lt;<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>
&gt; 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>&gt; Hey I prefer Tom&#39;s version! I shouldn&#39;t be racy if I read the
<br>&gt; resumeProcess and resume code correctly. The resumeProcess message has<br>&gt; no effect on non-waiting processes!<br><br></div>To the contrary. This code *introduces* a race condition when<br>manipulating the Semaphore&#39;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>&gt;<br>&gt; &nbsp;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | waitingProcess wakeupProcess |<br>&gt; &nbsp;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; waitingProcess _ Processor activeProcess.
<br>&gt; &nbsp;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; wakeupProcess _<br>&gt; &nbsp;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [(Delay forMilliseconds: (anInteger max: 0)) wait.<br>&gt; &nbsp;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; self resumeProcess: waitingProcess] fork.<br>&gt; &nbsp;&gt;
<br>&gt; &nbsp;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; self wait.<br>&gt; &nbsp; &nbsp; &quot;preempting here and getting the resumeProcess message sent would<br>&gt; have no effect - therefore no race!&quot;<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>&gt; &nbsp; &nbsp; &quot;in comparison having a semaphore getting signaled here would cause
<br>&gt; an excess signal on the sem: bad&quot;<br><br></div>First, the original code was guarded with a call to #unschedule which<br>would avoid a second signal if the &quot;real event&quot; occurs long enough<br>before the &quot;timeout event&quot;. 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. &nbsp;It&#39;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&#39;s needed.<br><br>Cheers,<br><font color="#888888"> &nbsp; - Andreas
<br><br><br><br><br></font></blockquote></div><br>