Browse Prior Art Database

First In First Out Exclusive Suspend Lock Management via Atomic Instructions Disclosure Number: IPCOM000126444D
Original Publication Date: 2005-Jul-18
Included in the Prior Art Database: 2005-Jul-18
Document File: 1 page(s) / 42K

Publishing Venue



This invention disclosure describes new locking primitives algorithms that allow fine grained locks to be implemented entirely independent of the operating system dispatcher. The algorithms are based off the zSeries atomic Compare and Swap instructions, however because many other platforms provide equivalent instructions, these algorithms apply to those platforms as well. These new independent locks can be allocated upon demand, as application demands warrant. By providing an independent suspend lock primitive, both the expense and overhead involved with global lock serialization techniques could be avoided.

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

Page 1 of 1

First In First Out Exclusive Suspend Lock Management via Atomic Instructions

The following interfaces are provided to initialize and implement the independent suspend lock primitive: InitLockHdr - Initializes consumer provided memory that is to become a Lock header control structure DestroyLockHdr - Cleans up a Lock header control structure

FastLockObtain - Attempts to obtain the exclusive Lock if it is immediately available

GetLockElemTok - Adds the caller to a list of waiters due to the unavailability of the Lock

LockElemWait - Blocks the caller until the Lock has been obtained

LockElemRels - Releases an obtained Lock

LockElemPurge - Provides the ability to purge any previously initiated interest in obtaining the Lock The overall design is to use a simple reverification technique when two independent atomic operations need to be serialized. Specifically function A must first make its update visible to function B, and then reverify that function B's state has not changed in such a way that makes function A's update inappropriate. When function B's state HAS CHANGED, function A processing must perform additional function B responsibilities. This same reverification process must also be performed by function B (against function A's state) AFTER it has made its update visible to function A.

In this case the two independent functions involved are: The adding of a new wait element to a waiter queue, and the freeing of the Lock. Whenever a new wait element is added to...