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.