1.  Technical Field
The present invention relates in general to a system and method for monitoring software locks.  More particularly, the present invention relates to a system and method for using instrumentation in a non-obtrusive manner to collect software lock metric data. 
2.  Description of the Related Art
Computer systems today typically include resources that are shared between multiple applications.  For example, a computer system may have a database that many applications, or threads, have the ability to access.  Computer systems use software locks to manage access to a shared resource.  A software lock is a language-level construct for providing mutually exclusive access to a shared resource in a multi-threaded environment. 
The computer system includes three layers which are an operating system layer, a middleware layer, and an application layer.  The operating system layer is the operating system which the middleware layer and application layer run on.  For example, the operating system may be a UNIX operating system.  The middleware layer is an application that runs on top of the operating system and interfaces with the application layer.  Using the example described above, the middleware layer may be a Java Virtual Machine (JVM).  The application layer is the layer where applications run.  Using the example described above, the application layer may be a Java application that runs on top of the JVM. 
One type of software lock is a “bimodal” software lock.  A bimodal software lock has two states which are “thin locks” and “thick locks.”  These states are also called “deflated” (for thin locks) and “inflated” (for thick locks).  Thin locks are located in the computer system's application layer and include characteristics such as speed, small size, and portability.  Thick locks are used when contentions arise for a thin lock (i.e. one application requests the thin lock when a different application currently owns the lock).  Thick locks are located in the computer system's operating system layer.  Thick locks are typically expensive in terms of processing time and should be avoided if possible. 
When a first application wishes to use a shared resource, the first application sends a request to a corresponding thin lock.  If the thin lock is not owned by another application, the first application acquires the lock without contention.  When a second application wishes to use the same shared resource while the first application owns the thin lock, contention arises for the thin lock.  A lock manager in the middleware layer is invoked and processes the second application's lock request.  The lock manager examines lock data structures to determine if a queue has been established to acquire a thick lock corresponding to the software lock.  The lock data structures include information pertaining to thick locks located in the operating system.  The lock manager may wait (i.e. spin) for a period of time to see if the first application releases the thin lock before adding the second application to the queue. 
Computer systems often include instrumentation to track system performance such as lock management performance.  A challenge found with existing instrumentation is the overhead associated with the instrumentation and that the overhead may degrade system performance and distort the data that the instrumentation is measuring.  For example, the instrumentation may use extensive processing time which, in turn, may slow down an application that the instrumentation is monitoring. 
Additionally, the computer system typically has garbage collection events which may occur during instrumentation data collection times.  A garbage collection event is occasionally performed which stops processing from performing other tasks.  For example, a garbage collection event may be performed to restructure, or defragment a database in order to allow the computer system to operate efficiently.  Garbage collection events may distort time-based metrics, such as the time an application takes to acquire a lock, if garbage collection events occur during instrumentation data collection periods. 
What is needed, therefore, is a system and method that monitors software locks with minimal overhead and removes garbage collection events from metric data.