Browse Prior Art Database

Semantically Rich Set of Seize Types Using the Classical Shared/Exclusive Seize Model

IP.com Disclosure Number: IPCOM000101975D
Original Publication Date: 1990-Oct-01
Included in the Prior Art Database: 2005-Mar-17
Document File: 5 page(s) / 187K

Publishing Venue

IBM

Related People

Holm, ML: AUTHOR [+3]

Abstract

A classical seize model contains two types of seizes: shared and exclusive. These two seizes can be implemented in a lock manager with two bits: one identifying a shared, and the other an exclusive seize. Unfortunately, these two bits do not provide the granularity necessary for supporting the semantically rich set of seize types necessary for promoting acceptable performance in high concurrency environments. Furthermore, it is usually difficult to enhance the seize manager itself since, in the interests of conserving space in the seize tables, two bits are generally all that are available for the seize identifiers. A method is needed that provides a full set of seize types while using only the two bits in the seize tables that traditionally identify shared and exclusive seizes.

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

Semantically Rich Set of Seize Types Using the Classical Shared/Exclusive Seize Model

       A classical seize model contains two types of seizes:
shared and exclusive.  These two seizes can be implemented in a lock
manager with two bits:  one identifying a shared, and the other an
exclusive seize.  Unfortunately, these two bits do not provide the
granularity necessary for supporting the semantically rich set of
seize types necessary for promoting acceptable performance in high
concurrency environments.  Furthermore, it is usually difficult to
enhance the seize manager itself since, in the interests of
conserving space in the seize tables, two bits are generally all that
are available for the seize identifiers.  A method is needed that
provides a full set of seize types while using only the two bits in
the seize tables that traditionally identify shared and exclusive
seizes.

      Standard shared and exclusive seizes conflict as shown in the
table in Fig. 1.  A shared seize is generally used to seize an object
when the data in that object is to be read, and an exclusive seize is
used when the object data is to be modified.  However, this means
that one object modifier prevents all object readers, or one object
reader prevents all object modifiers even if entirely unrelated
portions of the object are being read and modified.  It is obvious
that this mechanism is hardly conducive to high concurrency in this
object so three new seize types are defined: intent-shared, intent
exclusive, and shared intent exclusive (*) (see Fig. 2).

      The intent seizes are generally acquired at the object-level,
thus allowing readers and modifiers simultaneous access to the
object.  Shared and exclusive seizes are acquired on the more
granular portions of the object that must remain static, or which
will be in flux. Basically, an intent-shared or intent-exclusive
seize implies that the process intends to acquire a shared or
exclusive seize on an internal portion of the object.  A shared
intent exclusive seize allows read concurrency but prevents object
modifications by all processes other than the one which owns the
seize.

      Consider how a seize mechanism is usually implemented. There is
a pair of n-bit fields, where n is the number of seize types,
associated with each seize type.  One field, the hold bits, is a
unique identifier of the type of seize. The other field, the test
bits, identifies the type of seizes with which this seize conflicts.
A seize conflicts with another seize when the test bits of the seize
to be acquired logically ANDed with the hold bits of an already
granted seize produces a nonzero result.  For example, in the
classical shared/exclusive seize model the hold and test bits are
used (see Fig. 3).

      An intent-exclusive seize can be added with only two bits
available for test and hold by redefining the test and hold bits as
shown in Fig. 4.

      Much increase in concurrency can be achieved...