|
In a multitasking, multiprocessing environment, resource serialization
is the technique used to coordinate access to resources that are used by more
than one application.
Programs that change data need exclusive access to the data. Otherwise,
if several programs were to update the same data at the same time, the data
could be corrupted (also referred to as a loss of data integrity). On the
other hand, programs that need only to read data can safely share access to
the same data at the same time.
The most common techniques for serializing the use of resources are enqueuing
and locking. These techniques allow for orderly access to system resources
needed by more than one user in a multiprogramming or multiprocessing environment.
In z/OS®,
enqueuing is managed by the global resource serialization component and locking
is managed by various lock manager programs in the supervisor component.
- Global resource serialization
- The global resource serialization component processes requests for resources
from programs running on z/OS. Global resource serialization serializes access
to resources to protect their integrity. An installation can connect two or
more z/OS systems
with channel-to-channel (CTC) adapters to form a GRS complex to serialize
access to resources shared among the systems.
When a program requests access
to a reusable resource, the access can be requested as exclusive or shared.
When global resource serialization grants shared access to a resource, exclusive
users cannot obtain access to the resource. Likewise, when global resource
serialization grants exclusive access to a resource, all other requestors
for the resource wait until the exclusive requestor frees the resource.
- Enqueuing
- Enqueuing is the means by which a program running on z/OS requests
control of a serially reusable resource. Enqueuing is accomplished by means
of the ENQ (enqueue) and DEQ (dequeue) macros, which are available to all
programs running on the system. For devices that are shared between multiple z/OS systems,
enqueuing is accomplished through the RESERVE and DEQ macros.
On ENQ and
RESERVE, a program specifies the names of one or more resources and requests
shared or exclusive control of those resources. If the resources are to be
modified, the program must request exclusive control; if the resources are
not to be modified, the program should request shared control, which
allows the resource to be shared by other programs that do not require exclusive
control. If the resource is not available, the system suspends the requesting
program until the resource becomes available. When the program no longer requires
control of a resource, the program uses the DEQ macro to release it.
- Locking
- Through locking, the system serializes the use of system resources by
authorized routines and, in a Parallel Sysplex®, by processors.
A lock is simply a named field in storage that indicates whether a resource
is being used and who is using it. In z/OS, there are two kinds of locks: Global
locks, for resources related to more than one address space, and local locks,
for resources assigned to a particular address space. Global locks are provided
for nonreusable or nonsharable routines and various resources.
To use a
resource protected by a lock, a routine must first request the lock for that
resource. If the lock is unavailable (that is, it is already held by another
program or processor), the action taken by the program or processor that requested
the lock depends on whether the lock is a spin lock or a suspend
lock:
- If a spin lock is unavailable, the requesting processor continues testing
the lock until the other processor releases it. As soon as the lock is released,
the requesting processor can obtain the lock and, thus, control of the protected
resource. Most global locks are spin locks. The holder of a spin lock should
be disabled for most interrupts (if the holder were to be interrupted, it
might never be able to gain control to give up the lock).
- If a suspend lock is unavailable, the unit of work requesting the lock
is delayed until the lock is available. Other work is dispatched on the requesting
processor. All local locks are suspend locks.
You might wonder what would happen if two users each request a lock
that is held by the other? Would they both wait forever for the other to release
the lock first, in a kind of stalemate? In z/OS, such an occurrence would be known
as a deadlock. Fortunately, the z/OS locking methodology prevents deadlocks.
To
avoid deadlocks, locks are arranged in a hierarchy, and a processor or routine
can unconditionally request only locks higher in the hierarchy than locks
it currently holds. For example, a deadlock could occur if processor 1 held
lock A and required lock B; and processor 2 held lock B and required lock
A. This situation cannot occur because locks must be acquired in hierarchical
sequence. Assume, in this example, that lock A precedes lock B is the hierarchy.
Processor 2, then, cannot unconditionally request lock A while holding lock
B. It must, instead, release lock B, request lock A, and then request lock
B. Because of this hierarchy, a deadlock cannot occur.
|