[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
idea.
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