Smalltalk and Object Orientation: an Introduction - Free

The Semaphore class provides facilities for achieving simple synch ronization, it is simple because it
only allows for two forms of communication signal and wait. Essentially, a signal puts a 1 in the
queue representing the semaphore and wait pops a 1 off the semaphore. The advantage of this approach
is simplicity and eff iciency. the disadvantage of this approach is that more complex synchronization is
not possible. Of course, more complex synchronization can be achieved using semaphores and shared
queues, but the key thing is that it is not directly supported.
When a process sends a wait message to a semaphore, that process will only be allowed to proceed
if a corresponding signal has been sent to the semaphore. If there is no corresponding signal, then the
process will be suspended. It will only be resumed when such a signal is sent.
Semaphores are ordered queues. If five waits have been sent to a semaphore then the fifth wait will
only be serviced once five signals have been sent to the same semaphore. This means that they pay no
attention to the priority of the process ( unlike the scheduler). A high -priority process must wait in line
for a signal in just the same way as a low priority process.
There are two instance creation methods for the Semaphore class. These are:
Semaphore new.
Semaphore
forMutalExclusion.
This creates a new empty semaphore.
This creates a new semaphore with a single signal in it.
This is a special type of semaphore which is used in
association with a special message critical and provides
for mutual exclusion.
As stated above there are two synchronization messages; signal and wait:
aSemaphore signal. This increments the semaphore signal count.
aSemaphore wait. This increments the semaphore wait count and causes the
sender to suspend if fewer signals were previously sent.
An additional messag e to a semaphore is critical:. This should only be sent to a semaphore
which was created using the forMutalExclusion instance creation message. The format of this
message expression is:
aSemaphore critical: aBlock
This is useful if the block is accessing shared information. This message only allows the block to
execute if no other block controlled by the same semaphore is executing; otherwise, it causes the active
process to suspend until the block can be executed. In effect it is performing the following process:
• Send a wait message to the semaphore.
• Executes the block.
• Send a signal message to the semaphore.
31.3.2 Shared queues
When distinct processes access shared objects, then the access to those objects must be carefully
controlled. For example, if two objects were to access a common set of data and one was in the process
of adding some data, then when another (higher priority) process pre -empts it and attempts to perform a
different addition operation, the original changes might well be lost. Since the ori ginal addition was not
completed the set could be in a partially modified state, this could have extremely unpredictable results.
Smalltalk does not provide protected collection classes (although again these could be implemented
using semaphores etc.). Ins tead, Smalltalk provides a SharedQueue class which guarantees that only
one process will be able to access it at a time and that the expression being performed will execute to
completion without being pre -empted. The design of a shared qu eue is essentially that presented in the
Purple Book [Goldberg and Robson 1989], in Chapter 15 starting on page 258-265.
Elements can be placed in a shared queue using the nextPut: message, while elements can be read
from a shared queue using the next message. If no elements are currently in the shared queue when a
next message is sent, then the sending process is suspended until a nextPut: message is sent to the
queue. If three successive next messages are sent to an empty shared queue by three separate
263