[Vm-dev] Why isn't signalSemaphoreWithIndex() thread-safe?

Igor Stasenko siguctua at gmail.com
Sun Sep 20 22:09:03 UTC 2009

2009/9/21 Andreas Raab <andreas.raab at gmx.de>:
> Joshua Gargus wrote:
>> Let's say that there are two native threads A and B that want to signal
>> semaphores with indices 7 and 8, and that there are no other semaphores
>> to be signalled.  Let's say that thread A is running until just after
>> "semaphoresToSignalCountA" is incremented, but is interrupted before it
>> assigns the index.  Then thread B runs, increments
>> "semaphoresToSignalCountA" again (so its value is now 2), and sets
>> foo->semaphoresToSignalA[2] = 8.  Then A resumes and stomps this value
>> by setting foo->semaphoresToSignalA[2] = 7.  Now the semaphore with
>> index 8 will not be signalled, and just as bad, the index stored in
>> oo->semaphoresToSignalA[1] is now garbage that will be treated as a
>> semaphore-index to signal.
> On Windows, this case is handled by replacing signalSemaphoreWithIndex() by
> synchronizedSignalSemaphoreWithIndex() (sqWin32Window.c) in the vm proxy
> which serializes incoming signal requests.

What makes me think, that promoting synchronization protocol into
standard VM API would be nice
The platforms which doesn't provide multithreading, the function(s)
could be no-op. But on platforms
which providing it, they should be implemented to make VM thread safe.

> Cheers,
>  - Andreas

Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list