Replacing Semaphores with Mesa Monitors

John M McIntosh johnmci at smalltalkconsulting.com
Fri May 14 03:09:34 UTC 2004


On May 13, 2004, at 3:35 PM, Andrew P. Black wrote:

> I'm aware that this is a dangerous area to mess with - which is why I  
> was hoping not to.  But I don't really understand these comments.  Is  
> there a document that describes threading in the VM in more detail?

Er, not really.
It's safe to assume the OS or plugin or something will do an async call  
to signal a semaphore. This can occur on a process/thread outside the  
process/thread running the interpreter.


>
> My naïve thinking was that Squeak runs in a single OS thread, and  
> therefore there is no real concurrency, and that the interpreter main  
> loop was never preempted.  There are signals from the OS, however,  
> indicating things like data on a socket.  I imagined that these got  
> queued up somehow, and that the interpreter main loop would check the  
> queue each cycle.  Alternatively, I suppose it would be possible to  
> let the OS signal handlers directly execute the semaphore primitives,  
> but then one would have to do really hairy stuff to make sure that the  
> semaphore primitives were not made non-atomic with respect to the  
> signal handler executions.  Is this the problem that you are referring  
> to?
>
> 	Andrew

I'm not sure it needs to be hairy you should look at what it does now  
and see how it maps to what you
want to do.

--
======================================================================== 
===
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