Information Technology Reference
In-Depth Information
Shared objects, monitors, and syntactic sugar
We focus on shared objects because object-oriented programming provides a good
way to think about shared state: hide shared state behind public methods that provide
a clean interface to threads and that handle the details of synchronization.
Although we use object-oriented terminology in our discussion, the ideas are equally
applicable in non-object-oriented languages. For example, where a C++ program might
define a class for shared objects that defines public methods to manipulate its private
state variables and member variables in a well-defined way, a C program might define a
struct that includes synchronization variables and state variables as fields, and—rather
than having code that accesses the struct's fields scattered about—it might define a
fixed set of functions that operate on the struct's fields
Conversely, some programming languages build in even more support for shared
objects than we describe here. When a programming language includes support for
shared objects, a shared object is often called a monitor. Early languages with built-in
support for monitors included Brinch Hansen's Concurrent Pascal and Xerox PARC's
Mesa; today, Java includes built in monitor support via the
synchronized
keyword.
We regard the distinctions between procedural languages, object-oriented languages,
and languages with built-in support for monitors as relatively unimportant syntactic
sugar. We use the terms “shared objects” or “monitors” broadly to refer to a conceptual
approach to constructing shared state that can and should be used regardless of the
level of built in support in a particular programming language.
That said, for this topic, our code and pseudo-code are based on C++'s syntax, which
we believe provides the right level of detail for teaching the shared objects/monitors
approach. We prefer teaching with C++ to, say, Java because we want to explicitly show
where locks and condition variables are allocated and accessed rather than relying on
operations hidden by a language's built in monitor syntax. Conversely, we prefer C++
to, say, C because we think C++'s support for object-oriented programming may help
readers internalize the underlying philosophy of the shared object approach.
Scope and roadmap. As Figure 5.1 indicates, concurrent programs are built
on top of shared objects. The rest of this chapter focuses on the three bottom
layers of the gure|how to build shared objects using synchronization objects
and how to build synchronization objects out of atomic read-modify-write in-
structions. Chapter ?? discusses issues that arise when composing multiple
shared objects into a larger program.
5.3
Lock: Mutual Exclusion
A lock is a synchronization variable that provides mutual exclusion|when one
Denition: lock
thread holds a lock, no other thread can hold the lock (other threads are ex-
cluded.)
