Browse Prior Art Database

Non-Blocking Storage Management Method

IP.com Disclosure Number: IPCOM000061806D
Original Publication Date: 1986-Sep-01
Included in the Prior Art Database: 2005-Mar-09
Document File: 1 page(s) / 13K

Publishing Venue

IBM

Related People

Obermarck, RL: AUTHOR

Abstract

The invention relates to a new use for compare and swap type of atomic instructions in order to permit concurrent processes to obtain memory allocation in the event of failure of one or more accessing processes. The storage allocation algorithm is a three-tiered approach. 1. An attempt is made to reallocate a logical record of the required size from a queue of freed logical records. This is expected to be the normal mode of allocation once a steady state has been attained. 2. If no logical record of the correct size is available, an attempt is made to allocate the space from an existing GETMAINed block. Three results of this attempt are possible: a. The attempt was successful. In this case, the algorithm is considered complete. b. The attempt was unsuccessful, and the requestor is the one which depleted the block.

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

Page 1 of 1

Non-Blocking Storage Management Method

The invention relates to a new use for compare and swap type of atomic instructions in order to permit concurrent processes to obtain memory allocation in the event of failure of one or more accessing processes. The storage allocation algorithm is a three-tiered approach. 1. An attempt is made to reallocate a logical record of the required size from a queue of freed logical records. This is expected to be the normal mode of allocation once a steady state has been attained. 2. If no logical record of the correct size is available, an attempt is made to allocate the space from an existing GETMAINed block. Three results of this attempt are possible: a. The attempt was successful. In this case, the algorithm is considered complete. b. The attempt was unsuccessful, and the requestor is the one which depleted the block. In this case, the requestor will attempt to (branch-enter) GETMAIN to acquire a new large block for suballocation by itself and later requestors. c. The attempt was unsuccessful, and the requestor is not the one which depleted the block. In this case, the requestor will attempt to (branch-enter) GETMAIN for a block just large enough to contain the logical record being requested. 3. The last level of the algorithm is to invoke GETMAIN to obtain a block of storage. This level is serialized around the GETMAIN invocation by MVS locks. From the point of view of continued execution of the journal, a failure in (or during) any of the above allocation levels is not critical except during the GETMAIN process. The GETMAIN processing is protect...