Browse Prior Art Database

Self-Destruction Locks

IP.com Disclosure Number: IPCOM000106053D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 2 page(s) / 86K

Publishing Venue

IBM

Related People

Keller, RS: AUTHOR [+3]

Abstract

With the advent of shared resources (files and virtual memory) comes the implementation of locks to control access to the shared resources. These locks protect the shared resource from being updated by multiple users in a destructive way. The normal scenario for this is that a user wishing to update the shared resource tries to establish a lock on the data to be updated. Once the lock is established successfully, the user establishing the lock updated the data in the shared resource. After updating the shared resource, the user releases (or unlocks) the shared resource. A problem occurs when a user that establishes a lock fails to release it later

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

Self-Destruction Locks

      With the advent of shared resources (files and virtual memory)
comes the implementation of locks to control access to the shared
resources.  These locks protect the shared resource from being
updated by multiple users in a destructive way.   The normal scenario
for this is that a user wishing to update the shared resource tries
to establish a lock on the data to be updated.  Once the lock is
established successfully, the user establishing the lock updated the
data in the shared resource.  After updating the shared resource, the
user releases (or unlocks) the shared resource.  A problem occurs
when a user that establishes a lock fails to release it later

(because of a faulty program design, or an abnormal ending to a
command).

      The answer here is a self destroying (or self releasing) lock.
Consider a lock which is a 370 doubleword instead of a flag or a
fullword.  (Note: A 370 doubleword is 64 bits and is capable of
storing the system clock.)  The shared resource is unlocked when the
locking variable is set to a zero and locked when the locking
variable is set to anything other than zero (positive or negative).
Given this, a user can lock the shared resource by storing a system
clock into the locking variable.

      The userid that controls the shared resource sets a time limit
for locking of the shared resource.  Any user of the shared resource
must complete their update within the time limit.  The selection of
the time limit (done by the controlling user) is based on the type of
activity being done during the update.  For example, if the shared
resource is some type of locally attached virtual memory, then the
time limit should be relatively short (like 5 seconds).  However, if
the shared resource is some type of I/O device, then the time limit
should be longer (like 5 minutes).

      A program trying to establish a lock of the shared resource
would first check the locking variable to see if the locking variable
is zero.  If the locking variable is not zero (and therefore locked
by another user or program), then the program would check to see if
the lock has expired.

      If the lock has expired, then the program trying to obtain the
lock on the shared resource, would unlock the shared resource by
changing the locking variable to zero.  Once the locking variable is
zero, then the program is free to obtain the lock.

      The following is 370 language assemble program that implements
the self destructing lock.  In the example, assume that "LOCK" is the
doubleword locking variable.  Also assume that "LIMIT" (another
doubleword) is the amount of time that the controlling user has set
for the length of time a lock can be held.

  AAAA    DS    0H           Alignment
          STCK  DWORD        Get the current clock value
          LM    R2,R3,DWORD  First we get the current time
          LTR   R2,R2     ...