Manuscript (Case [Issue]22477) Debugging - DelayScheduler cleanup and refactoring

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Manuscript (Case [Issue]22477) Debugging - DelayScheduler cleanup and refactoring

Pharo Issue Tracker
Manuscript Notification
avatar
Ben Coman revised a previous entry on Case 22477: DelayScheduler cleanup and refactoring:
Bug in Project:  Debugging: 1. Pharo Image  •  You are subscribed to this case
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} Microsecond Ticker and Delay {time-base}TickerSI MillisecondTicker
plus associated si
mulation   classes ,
so that the tests use the simulation classes.   
for use by tests.  I've kept the millisecond option since it may be beneficial for future embedded 32-bit platforms.
A nice side-effect of this separation 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
part ?

I fear I've made the ticker simulation too complex.  To help
observe reviewers follow the multi-threaded interactions I've left in some conditional debug break 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 advice on any coupling this has on any of with the bootstrap process.
Priority Priority: 3 – Must Fix Status Status: Work Needed
Assigned To Assigned to: Everyone Milestone Milestone: Later

Go to Case
No longer need updates? Unsubscribe from this case.

Don't want Manuscript notifications anymore? Update your preferences.

Manuscript

_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
https://lists.gforge.inria.fr/mailman/listinfo/pharo-bugtracker