Smalltalk and Object Orientation: an Introduction - Free

Once the process wakes up it can determine which of the processes cur rently waiting to use the
processor should be resumed next. One way in which this can be done is to regroup the processes in the
waiting queue of the highest priority queue that has more than one process. Thus ensuring that a
different process is at the he ad of the queue each time the user defined scheduler process “goes back to
sleep”.
Check to see if time slicing is already being used.
If not set up the a new process to sleep for 5 milliseconds
and then to initiate the time slicing process.
Set the process to have the highest available priority.
Schedule the process for execution.
Figure 31.1: The time slicing algorithm
31.4.1 The source code for the example
As explained above the mechanism which allows this time slicing scheduler to work is the user of a
Delay. This delay forces the user extensio ns to the scheduler to sleep. When it wakes up it selects a
new process for execution using the slice method. It then goes back to sleep.
This continuous sleeping and slicing cycle can be achieved by spawning a new process (with the
highest allowable priority). This process continually loops, sleeps and slices. The method which initiates
this behaviour is startTimeSlicing. This method, defined in time slice process protocol, uses the
algorithm in Figure 31.1. The actual Smalltalk method is presented below:
startTimeSlicing
"self startTimeSlicing"
TimeSliceProcess notNil ifTrue: [^self].
TimeSliceProcess :=
[[true] whileTrue:[(Delay forMilliseconds: 5) wait.
Processor slice]] newProcess.
TimeSliceProcess priority: (Processor highestPriority).
TimeSliceProcess resume.
Of course having set up such a process we must p rovide some way of killing the process. If this is
not done, then this process will always run (until the image is deleted). This is in fact the reason why the
new process was stored into a variable named TimeSliceProcess. This is of course a global
variable and could easily have been stored as an instance variable of the ProcessorScheduler class.
However, for ease of debugging it is often easier to store a process such as this in a global variable. This
is because it is at a higher priority level then most user processes. If an unexpected “feature” has been
introduced, the process can be killed by sending the message terminate to the contents of the
TimeSliceProcess global variable, either in a normal debugger or an emergency debugger.
The stopTimeSlicing method provides a rather more managed way of stopping the time slicing
process. This does send the terminate message to the time slicing process and then sets the global
variable to nil. This method is available in the 'time slice p rocess' method category. The method
definition is:
stopTimeSlicing
"self stopTimeSlicing"
TimeSliceProcess notNil
ifTrue:[TimeSliceProcess terminate. TimeSliceProcess := nil]
So far we have set up the means by which a new, user defined pr ocess, can interrupt lower priority
processes, and alter the process which will get run next. However, what we have not done is to define
how this re-ordering of processes will occur.
The method slice in the method protocol process state change of the ProcessorScheduler
performs this reorder. This is where the real meat of the time slicing operation occurs. The algorithm
describing this method’s operation is:
1. Find the first process priority queue which contains more than one process.
2. Remove the front process from this list and add it to the end of the list.
265