Browse Prior Art Database

Locking Architecture in a Multiple Virtual Memory Multiprocessing System

IP.com Disclosure Number: IPCOM000080512D
Original Publication Date: 1973-Dec-01
Included in the Prior Art Database: 2005-Feb-27
Document File: 3 page(s) / 16K

Publishing Venue

IBM

Related People

Gum, PH: AUTHOR [+8]

Abstract

The term locking is used to refer to methods employed to assure sequential access to serially reusable operating system resources. Previous versions of the IBM OS/360/370 operating system guarded serially reusable resources, by executing all referencing functions in the disabled state. The only detectable condition that such a resource was in use was the disabled state.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 3

Locking Architecture in a Multiple Virtual Memory Multiprocessing System

The term locking is used to refer to methods employed to assure sequential access to serially reusable operating system resources. Previous versions of the IBM OS/360/370 operating system guarded serially reusable resources, by executing all referencing functions in the disabled state. The only detectable condition that such a resource was in use was the disabled state.

It was recognized that improved operating system service could be rendered, if more discriminating methods of managing access to serially reusable resources were provided. Better response to realtime service demands would result from diminishing the time spent in the disabled state. More effective use of the CPU processing power available in a tightly-coupled multiprocessing configuration would result, if the contention for access to supervisor services could be reduced. This could be accomplished by taking advantage of the observation that the supervisor consists of a collection of functions, some of which are relatively independent of each other. Given a diverse system load, each CPU will require supervisor services somewhat randomly. Thus contention would result only when the same service was requested at the same time, the probability of which is reduced by increasing the number of functions separately useable thus increasing system efficiency.

Described is the locking mechanisms implemented in the OS/VS2 Release 2 operating system. The prominent features of the design are:

1. Locks are represented by control blocks in main storage, the contents of which are maintained with the S/370 instructions Compare-and-swap. Race conditions are resolved in the hardware as part of the implementation of these instructions.

2. Locks are classified as one of two types according to how the system responds when an already held lock is requested. For spin type locks, the requesting CPU delays by repeatedly requesting the lock until it is available. To assure that a lock will remain unavailable for only a short duration, the owning CPU must remain disabled, and the process it is executing must not be subject to page faults.

To prevent the requesting CPU from entering an indefinite delay because the owning CPU malfunctions and is unable to free the lock, the delay loop executed by the requesting CPU enables for signals signifying owning CPU malfunctions.

Suspend type locks cause the requesting CPU to abandon the requesting process when a closed lock is requested. The abandoned process is queued to await the opening of the lock. This is accomplished such that the presence of pending processes is noted when the lock is opened. When the lock opens, all pending processes are readied to again contend for the lock, in priority order of the processes. Thus, rather than delaying, the requesting CPU instead selects some other, unblocked, process to execute.

The hold time of suspend type locks can be relatively long. T...