On 3 Jan 2001, Alexandre Julliard wrote:
> Ove Kaaven <[EMAIL PROTECTED]> writes:
>
> > OK, this code may look all fine and dandy, even for sendmessages. But what
> > happens when an optimizing C compiler like gcc gets run on it? Well, it
> > figures that the changeBits are tested at [2], so when it gets to [3], it
> > sees no change, and optimizes [3] out... so, instant race condition.
>
> It does not make any difference whether the compiler optimizes it out
> or not, you still have the same race.
No? Ok, let me recheck my understanding...
on the left the various stages of WaitBits, on the right what SetWakeBit
would do if it was invoked at that stage of WaitBits...
WaitBits SetWakeBit
-------- ----------
starts (no wakeMask)
set changeBits, return
tests changeBits
set changeBits, return [X]
tests wakeBits for sendmessage
set changeBits, return [X]
sets wakeMask
set changeBits, resets wakeMask, wakes
tests changeBits (optimized out)
set changeBits, resets wakeMask, wakes
waits for wake
returns to start
The two spots marked [X] would be handled fine if the second test wasn't
optimized out (well, a wake would probably be signaled, and WaitBits would
never wait for that wake, which isn't elegant, but that would at least be
erring on the safe side).
None of the other spots would be problematic, as far as I can see.
> And adding volatile doesn't help, the bits can always be changed after
> they are tested (volatile is almost always the wrong fix for a race
> condition anyway).
But if the bits are changed after the wakeMask is set, then SetWakeBit
signals the queue, so it would get out of the following wait anyway? Or
what? As far as I can see, the code handles all likely conditions... the
"volatile" just protects the important checks from being optimized out, it
doesn't have much to do with the race condition itself...
Of course, I'm not going to stop you from fixing the unlikely conditions
too, but I wanted this to work reliably now, and when this fix appeared
simple and correct enough...
