Replacing Semaphores with Mesa Monitors
John M McIntosh
johnmci at smalltalkconsulting.com
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.
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