Replacing Semaphores with Mesa Monitors

John M McIntosh johnmci at
Thu May 13 16:22:37 UTC 2004

If one messes greatly with the semaphore signaling in the VM you should  
examine the code carefully. On os-9 semaphore signaling can
occur on another thread (Open transport network processing), thus  
leading to a race condition on whatever is being managed. Right now the  
interpreter thread reads/process a queue of pending semaphore signals,  
where as plugins & other threads can put signals on a different queue.  
Then things get switched when the VM again processes pending signals.  
Although this is not perfect, it has a very small window of failure.  
Unlike the original code many years back that allowed concurrent  
unmanaged access between different OS processes. Perfect code would  
require usage of a hosting OS mutex semaphore construct.

On May 13, 2004, at 12:39 AM, Avi Bryant wrote:

> On May 13, 2004, at 12:29 AM, Andrew P. Black wrote:
>> Yes, that is of course right.  It would be impractical to go "cold  
>> turkey".   I don't know enough about the way that signals or  
>> interrupts are translated into Squeak to comment on whether it would  
>> be a problem for the VM to support both mechanisms for a while.  I  
>> was hoping that the representations could be close enough that the VM  
>> wouldn't have to care which it was signalling - which is when I came  
>> up against the problem that care or not, it decided to insert an  
>> explicit test.
> It would be fairly easy to build a VM without these checks.  If you  
> load VMMaker, you can see them in Interpreter>>primitiveSignal and  
> Interpreter>>primitiveWait.  Comment out the checks, and follow the  
> VMMaker docs to regenerate the sources and rebuild.
> If you happen to be on Mac OS X I can try to build a VM for you, just  
> let me know.
> Avi
John M. McIntosh <johnmci at> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.

More information about the Squeak-dev mailing list