Smalltalk and Object Orientation: an Introduction - Free

processes, all three processes will be suspended. When a subsequent nextPut: message is sent to the
shared queue, the first process to have sent a next message will be resumed. An additional message
available is the peek message. This returns the next item i n the shared queue, however unlike the
next message, it does not remove it from the queue. The instance creation methods for a shared queue
are:
SharedQueue new.
SharedQueue new: anInitialSize.
Both these messages return a shared queue. The three messages used with shared queues are:
aSharedQueue next.
aSharedQueue nextPut:
aSharedQueue peek.
The following passage is taken from page 36 [Lalonde and Pugh 1991b].
“In general, creating new shared classes is relatively easy. A specialization of the origina l
class is created with two new instance variables to play the role of the two semaphores (one
semaphore for co -ordinating user access and another for mutual exclusion while executing
critical code). Then, all operations with side effects are revised using the following template.
If a method being revised is called aMethod, the critical section code is simply a variant of
“super aMethod.”.”
For example:
aMethod: anObject
mutualExclusionSemaphore critical: [super aMethod: anObject].
readingSynchronisationSemaphore signal.
or
aMethod
| anElement |
readingSynchronisationSemaphore wait.
mutualExclusionSemaphore critical: [anElement := super aMethod].
^anElement.
31.4 A concurrent Smalltalk example
This section presents an example t o show how time slicing could be done within Smalltalk using the
current process scheduler (based on an example produced by Hubert Baumeister - see end of section).
The basic idea behind the effective control of multiple processes within Smalltalk is the i ntroduction of
a high priority process. This process wakes up every few milliseconds and regroups the processes in the
waiting queue of the highest priority that has more than one process. It then goes back to “sleep” for a
few milliseconds. It is thus time slicing between the various processes at the lower priority.
The approach taken in this section is that if it is necessary to develop a preemptive scheduler (that is
one in which the processor time is shared between a given number of processes, rather than dedicated to
a single process), then this can be done by using the facilities provided by the standard scheduler. In
effect this results in two schedulers. One, is the system scheduler, the other is a user defined scheduler.
The system scheduler is still used to actually enable a process to execute. For example, it is still this
scheduler which can suspend a process when a signal is sent to a semaphore.
The user defined scheduler is used to manage the queues of user processes waiting to be handed to
the system scheduler. These queues are controlled by the user scheduler when ever it “wakes up”. Of
course, in order for it to gain control of the processor it MUST HAVE a HIGHER PRIORITY than all
other user processes. It can then interrupt the user processes and select which process to initiate.
The key to the user defined scheduler is that it “wakes up” every few milliseconds. This can be
simply and easily achieved using a Delay. This will send the process to sleep for the period of the
delay. Actually, it wi ll cause the process to suspend until the timer associated with the delay period
sends the process a resume. It is this resume which will cause it to take control of the processor again.
264