[M3devel] Win32 threads

[Tony Hosking]

If the documentation is true then it is essentially useless in  
general.  Typical MS.  On the other hand, several MS sources on the  
Web claim that it *is* atomic.  Perhaps they should figure out what  
they really mean.

Antony Hosking | Associate Professor | Computer Science | Purdue  
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 29 Sep 2009, at 16:12, Jay K wrote:

> SignalObjectAndWait is widely mentioned as important to implementing  
> condition variables on Win32, however it is documented as not being  
> atomic.
> Search the web:
> http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx
>
> "Note that the "signal" and "wait" are not guaranteed to be  
> performed as an atomic operation. Threads executing on other  
> processors can observe the signaled state of the first object before  
> the thread calling SignalObjectAndWait begins its wait on the second  
> object."
>
> So it isn't useful, right?
>
> Thanks,
>  - Jay
>
>
> From: hosking at cs.purdue.edu
> To: m3devel at elegosoft.com
> Date: Tue, 29 Sep 2009 13:54:48 -0400
> Subject: [M3devel] Win32 threads
>
> I believe that the hangs we are seeing are because of the race  
> present in AlertWait, which permit a thread to miss seeing an alert  
> before waiting on the condition.  We want the thread only to wait if  
> there has been no alert.  Unfortunately, the alert is only protected  
> by the global mutex, which must be release before waiting.   
> Currently, we release the mutex, then wait, with the resulting  
> race.  This requires a more complicated handshake than currently  
> implemented.  Perhaps using SignalObjectAndWait instead as well as a  
> Win32 mutex on each thread.  Similarly to ThreadPThread.m3.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue  
> University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090929/c504143f/attachment-0002.html>