[VM][Win32] Can plugin DLL use synchronizedSignalSemaphoreWithIndex()?

John M McIntosh johnmci at smalltalkconsulting.com
Sun Aug 25 18:44:36 UTC 2002


>On Sun, Aug 25, 2002 at 05:16:43PM +0200, Andreas Raab wrote:
>>  David,
>>
>>  I think you don't need this any longer. A while ago John fixed various
>>  of the issues due to external synchronization in the VM and the Win32
>>  code predates these changes. If I'm not mistaken, there is no problem
>>  with just using "signalSemaphoreWithIndex".
>
>Good, thanks. I'll just call signalSemaphoreWithIndex directly.
>
>As a general rule, is it permissible to call signalSemaphoreWithIndex
>from a Win32 thread other than the one in which the interpreter is
>running? I think it should be OK as long as I take care not to allow
>two or more of my Win32 threads to be executing signalSemaphoreWithIndex
>at the same time, but I don't have any experience programming threads
>on any platform, so I'm more or less fumbling my way through this.
>
>Dave

A few years back I looked at this and rewrote the code because the 
original code was very very unsafe when running in a multi-thread 
environment. At the time I would lose whole sets of signals as the 
mac open transport async events completed and the interp.c fought 
over the pending signals, both tasks would attempt to read and write 
to the same array.

Now pending interrupts are place in an array and the VM asked to wake 
up and process them. When this happens the VM the reader switches the 
write array between two arrays to avoid the reader/writer collision, 
and then reads the now read only array.

Still it's not quite thread safe. If you look at

signalSemaphoreWithIndex
and
checkForInterrupts

there still is the possibility from say a DLL running on a different 
thread to lose a signal, a collision at write time for example. 
Correcting this requires an OS level mutex lock, which might not be 
possible in all platforms. Tho I guess we could code up some entry 
points and null them out as the default, and or use a thread safe 
mutex queue, again an OS issue.

Now if you want to suggest a change here and have an example of a 
failure situation I'm all ears. Mmm also only 500 outstanding 
interrupts at any time.

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================



More information about the Squeak-dev mailing list