Browse Prior Art Database

Efficient Tracking of Lock Ownership for Recovery Purposes

IP.com Disclosure Number: IPCOM000109891D
Original Publication Date: 1992-Sep-01
Included in the Prior Art Database: 2005-Mar-24
Document File: 2 page(s) / 95K

Publishing Venue

IBM

Related People

Brenner, LB: AUTHOR

Abstract

Lock ownership is considered a part of the interruption context of a thread instead of a property of the thread per se.

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

Efficient Tracking of Lock Ownership for Recovery Purposes

       Lock ownership is considered a part of the interruption
context of a thread instead of a property of the thread per se.

      The structure representing saved context during interrupt
handling was changed to include new fields for lock ownership
tracking, as shown in the fragment below. Note that the saved
hardware context (gprs, etc.) is that of the previous or interrupted
level, while the lock ownership information represents the state of
the current interrupt handling level.

                            (Image Omitted)

      In addition, all lock structures capable of representing an
exclusively held resource include a field for linking all such locks
currently owned in a given context together.

      By recording lock ownership in the structures representing
saved context, the process of such ownership recording is itself
protected from almost all the problems of the ownership code being
interrupted.  Even though the ownership structures may be left in an
inconsistent state during the time the support code is interrupted,
we know that any new operations on locks will be performed against
the newly created interruption context, and therefore will not be
damaged by the inconsistent state at the level "below."  Since all
locks that are chained together to record ownership are themselves
owned by the current thread, no additional serialization mechanism is
needed to guarantee integrity of the chains.

      The one operation that is not obviously "safe" with this scheme
is lock recovery itself.  The back pointer field in the current
context is used to access the previous context for this purpose,
which is then visible in a possibly inconsistent state.  A passive
recovery scheme that is not the subject of this disclosure prevents
recovery when the lock ownership data may have been corrupted due to
failures within the lock ownership handling routines themselves.

      The implementation details to support this approach are fairly
simple.  Spin locks, and...