Browse Prior Art Database

Method for split locks

IP.com Disclosure Number: IPCOM000007233D
Publication Date: 2002-Mar-06
Document File: 2 page(s) / 32K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for split locks. Benefits include improved performance.

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 50% of the total text.

Method for split locks

Disclosed is a method for split locks. Benefits include improved performance.

Background

              Synchronization is important for many applications. While most programming systems provide synchronization libraries, some major programming languages have synchronization built into the language itself. Efficient implementation of synchronization primitives has been studied extensively and determined to be a bottleneck for important applications.

              The disclosed method speeds up two important primitives, lock and unlock, by providing a way to factor out work common to the corresponding operations. In a conventional synchronization model, a lock is first acquired (using the lock operation) and later released (using the unlock operation). The time needed to acquire or release a lock varies depending on the workload. The operations are faster if contention does not occur.

              Typically, every object has a lock associated with it. Each object has two extra fields in addition to the fields declared by the user: the vtable pointer and a header word. The vtable pointer is used for type identification and for method dispatch. The header is used for synchronization and, optionally, for garbage collection and hashing. All three functions can be implemented to use the same header word.

              There are two major resource costs of the uncontested lock:

•              Assigning the thread ID

•              Performing an atomic operation to insert the ID in the header

              A conventional lock implementation provides two functions named monitorenter and monitorexit (see Figure 1). They call get_thread_id() twice, producing the same result in both calls.

              Multiple implementations may exist for the function get_thread_id(). In essence, they can all be reduced to the problem of accessing Thread Local Storage (TLS). On...