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