Browse Prior Art Database

Determining Reasons for Contention On a Multiply Used Lock

IP.com Disclosure Number: IPCOM000121884D
Original Publication Date: 1991-Oct-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 3 page(s) / 124K

Publishing Venue

IBM

Related People

Arwe, JE: AUTHOR [+2]

Abstract

Current lock contention analysis techniques can detect that contention for a lock is occurring but, if the lock is used for more than one reason, not the reason for the contention. This article describes a method to detect that contention is occurring and determine the reasons for the contention while not perturbing the system being observed.

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

Determining Reasons for Contention On a Multiply Used Lock

      Current lock contention analysis techniques can detect
that contention for a lock is occurring but, if the lock is used for
more than one reason, not the reason for the contention. This article
describes a method to detect that contention is occurring and
determine the reasons for the contention while not perturbing the
system being observed.

      The method is to always trace, before the contention occurs,
the minimum data required to determine at a later time what functions
were running and contending for the lock.  This data is saved so that
subsequent data reduction can detect which lock obtain requests
resulted in contention, what function was requesting the lock when
the contention occurred, and what function was holding the lock
causing the contention.  The trace data is captured, written to DASD,
and analyzed by programs running asynchronous to the in-line code
making the trace entries.  The method has the following capabilities.
      -    It can detect reasons for delay, which functions cause
delay, which functions experience delay, and all interrelationships
and frequencies.
      -    It uses, before the fact, asynchronous, unserialized, lock
obtain trace entries in combination with serialized lock release
trace entries to determine lock obtain order and contention.
      -    It has negligible impact on the observed system.
      -    It can work for any type of lock or enqueue and can be
enhanced to determine the length of delays.

      Each trace entry (32 bits) contains a function identifier and a
processor identifier.  There are two types of entries: obtain entries
and release entries.  An obtain entry is made in an unserialized
state just prior to a function requesting the lock.  Each function
always does this prior to each lock obtain request.  A release entry
is made just prior to releasing the lock.  It is important that
release entries be made while serialized by the lock because the
processor identifier in the release entries is used to determine lock
obtain order.  The trace entries are made in-line during a normal
system operation.  The trace does not perturb the system under
observation because it takes very few instructions (about 25) and
requires no additional serialization beyond compare and swap.

      The data writer and data reduction programs run asynchronous to
the tracing code.  The data writer wakes up periodically and writes
the trace entries to DASD.  The data reduction program reconstructs
the sequence of events and the contention the system experienced from
the trace entries.  The function identifiers in the obtain entries
are used to determine which functions requested or are ho...