[squeak-dev] Delay scheduling lacks atomicity

Igor Stasenko siguctua at gmail.com
Wed Jun 25 00:09:15 UTC 2008


Here the two lines of code, from Delay>>activate, which making me feel bad:

TimingSemaphore initSignals.
Delay primSignal: TimingSemaphore atMilliseconds: resumptionTime.

Things can go wild, if VM will signal previously scheduled timer
semaphore between first line and second line.

The more appropriate code would be:

Delay primSignal: nil atMilliseconds: 0. "reset VM timer, so there is
no chance that TimingSemaphore can be signaled in between"
TimingSemaphore initSignals.
Delay primSignal: TimingSemaphore atMilliseconds: resumptionTime.

Without it, there are chance that delay can be signaled prematurely,
and also a TimingSemaphore will have an excessive signals after VM
signal it again.

I not sure if this is possible at all. VM checks for interrupts at
each real send.
A primitive , which is in #primSignal:atMilliseconds: is not real
send, so maybe its ok here, but
i would not put much trust into it.
The code should be written in a way, that it impossible to break it
regardless on how often VM checks for interrupts.

A more reliable, would be is to change primitive and reset signals
counter of installed semaphore.  This will ensure atomicity.
So, a primitive would behave as following:
- reset semaphore signals
- schedule semaphore signal at given millisecond clock value

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list