|
|
This is my long promised cleanup of the delay scheduling system. I've been polishing some minor points for a few months and its time to put it out for review.
My original refactoring of the class-side code inherited from Squeak had left alone the mutex variable in parent class even though it was no longer used.
Now at the top level there is DelayNullScheduler which does nothing but define the minimum interface required to prevent errors in the rest of the system.
Subclassed from that is DelayBasicScheduler which provides the main algorithm without synchronization protection. This works fine but is fragile to changes in process scheduling semantics.
Subclassed from that are two classes add synchronization: DelayMutexScheduler and DelaySemaphoreScheduler.
I hope this arrangement helps highlight the separate aspects of the system.
I believe the existing code has a risky corner case related to suspending the delay scheduler for shutDown during a snapshot.
The accessProtect mutex only protects against calls from user code and not from the VM waking up the timingPriority loop to potentially expire delays at a higher priority than the snapshot process.
I've replaced that with semaphore immediately following the timingSemaphore suspension point in #timingPiorityRunEventLoop to guarantee the VM can't wake up the loop.
Previously some unit tests were a bit awkward in how they interfered with the system's active delay scheduler.
I've extracted the VM interaction code into separate Delay{time-base}Ticker and Delay{time-base}TickerSImulation classes,
so that the tests use the simulation classes. A nice side-effect of this is highlighting that the main algorithm is independent of a particular time-base.
In the back of my mind I'm playing with an idea that when multi-threaded callbacks are implemented, this separation of "ticker" might
help experiment with wakeup ticks coming directly from native timers rather than a loop in the VM checking the time.
@holger, I've refactored your DelayTickerlessScheduler into DelayUnconstrainedTicker. Could you take a particular focus on reviewing that?
I fear I've made the ticker simulation too complex. To help observe the multi-threaded interactions I've left some debug points in
which can be enabled before running tests by manually evaluating a line in TestDelayBasicSchedulerMicrosecond>>setDebugOnOff .
You just need to be careful not to step <Over> any #wait or the system hangs. Use <Proceed> instead.
I've not removed the old hierarchy yet, so these changes can be evaluated in an existing image.
I need to work out what effect this has on any of the bootstrap process.
|
|
|
Priority: 3 – Must Fix
|
|
Status: Work Needed
|
|
Assigned to: Everyone
|
|
Milestone: Later
|
Go to Case
|
|
Locked
Debugging: 1. Pharo Image
• You are subscribed to this case
