Smalltalk and Object Orientation: an Introduction - Free

31. Concurrency in Smalltalk
31.1 Introduction
This chapter presents and explains a short example of how concurrency can be accomplished wit hin
Smalltalk. It also considers lazy evaluations (i.e. you only perform the evaluation if you absolutely have
to), futures (you start an evaluation now which you will need later) and persistence.
The remainder of the document is structured in the followin g manner: Section two introduces the
concept of concurrency, Section three briefly discusses processes within Smalltalk. Section four
introduces the concepts used in the time slicing scheduler and Section five explains how future and lazy
evaluators may be implemented in Smalltalk.
31.2 Concurrent processes
The concepts behind object oriented programming lend themselves particularly well to the concepts
associated with concurrency. For example, a system can be described as a set of discrete obj ects
communicating with one another when necessary. In most Smalltalk implementations, only one object
may be executing at any one moment in time. However, conceptually at least, there is no reason why
this restriction should be enforced. For example, the basic concepts behind object orientation still hold,
even if each object executes within a separate independent process.
Traditionally, a message send is treated just like a procedural call, in which the calling object’s
execution is blocked until a respo nse is returned. However, we could extend this model quite simply to
view each object as a concurrently executable program module, with activity starting when the object is
created and continuing even when a message is sent to another object (unless the re sponse is required
for further processing). In this model, there may be very many (concurrent) objects all executing at the
same time. Of course this introduces issues associated with resource allocation etc. but no more so than
in any concurrent system.
One implication of this concurrent object model is that objects are necessarily larger than in the
traditional single execution thread approach. This is because the overhead of having each object as a
process. A process scheduler for handling these process es and resource allocation mechanisms mean
that it is not feasible to have integers or characters etc. as separate processes. (Note in Smalltalk integers
etc. are objects. In such a system there might be a separate type of object which is a concurrent obje ct
which is assumed to be a large grained object).
Smalltalk has limited built -in support for concurrency. However, it does support Processes and
Semaphores as primitive types. Other conventional inter -process communication and protection
mechanisms such as SharedQueues and critical regions, are implemented in terms of these primitives.
However, the processor scheduler (part of the virtual machine) implements a naive non -preemptive
scheduling policy, with limited support for re-scheduling within a particular priority level. Further, once
a high -priority process is running, no lower priority process will run until the high priority process
suspends or terminates. For these reasons, the basic Smalltalk system contains only a few processes and
typical applications using concurrency do not create more than a few tens of processes.
However, as the source code is available to the developer it is possible to extend the scheduler such
that a pre-emptive policy is introduced. This is described in Section 3 following on from a discussion of
the facilities provided in Smalltalk which enable the construction of such a scheduler.
261