Browse Prior Art Database

Problem-Determination for Forgotten Locks

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

Publishing Venue

IBM

Related People

Keller, RS: AUTHOR

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 updates the data in the shared resource. After updating the shared resource, the user releases (or unlocks) the shared resource.

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

Problem-Determination for Forgotten 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 updates 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).  This can leave the shared resource in a locked
state.  It then becomes a problem determination task to determine the
user and code that left the shared resource locked.  The current art
does not allow for sufficient problem determination tools to
determine how the lock got set.  The answer here is using the lock to
identity the program and the address that locked the shared resource.
This can be done by using a doubleword for the locking variable
instead of a flag or a fullword.  The shared resource is locked, if
the locking doubleword is zero.  If the locking doubleword is not
zero (positive or negative), then the shared resource is locked.
When the shared resource is locked, half of the doubleword is used to
identify the program that locked the shared resource.  The other half
identifies the address of the command that lock...