Browse Prior Art Database

Safe Object Locks in a Multi-threaded Environment

IP.com Disclosure Number: IPCOM000015761D
Original Publication Date: 2002-May-16
Included in the Prior Art Database: 2003-Jun-21
Document File: 1 page(s) / 38K

Publishing Venue

IBM

Abstract

This invention applies to a multithreaded environment where there is a requirement to associate an object lock with an object on creation. The object lock might be allocated from memory, from a pool of existing locks, or be embedded within the object itself. Problems arise when the object is destroyed. The lock cannot be de-allocated when the object is destroyed and its memory freed because another thread may be waiting for the lock (to lock the owning object), and if the lock is never de-allocated this will result in leakage (of lock memory). Furthermore, if the lock is only released and not de-allocated when the object is destroyed, not only does this result in leakage but another thread waiting for this lock will obtain the lock for a nonexistent object or for a totally different object if the lock was released and immediately reallocated to a new owning object. In the solution described here, object locks, once allocated, are stored in a pool from where they can be reallocated when they are not in use. The following additional information is associated with each object lock (for example as fields within a lock structure or as instance data within a lock object): owned: lock is owned flag This indicates whether an individual lock within a pool of locks is currently owned, or unowned. When owned it is associated with an object. When unowned it is available for reallocation to a new object.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 65% of the total text.

Page 1 of 1

Safe Object Locks in a Multi-threaded Environment

This invention applies to a multithreaded environment where there is a requirement to associate an object lock with an object on creation. The object lock might be allocated from memory, from a pool of existing locks, or be embedded within the object itself. Problems arise when the object is destroyed. The lock cannot be de-allocated when the object is destroyed and its memory freed because another thread may be waiting for the lock (to lock the owning object), and if the lock is never de-allocated this will result in leakage (of lock memory). Furthermore, if the lock is only released and not de-allocated when the object is destroyed, not only does this result in leakage but another thread waiting for this lock will obtain the lock for a nonexistent object or for a totally different object if the lock was released and immediately reallocated to a new owning object.

     In the solution described here, object locks, once allocated, are stored in a pool from where they can be reallocated when they are not in use.

     The following additional information is associated with each object lock (for example as fields within a lock structure or as instance data within a lock object): owned: lock is owned flag

     This indicates whether an individual lock within a pool of locks is currently owned, or unowned. When owned it is associated with an object. When unowned it is available for reallocation to a new object.
owner identifier: uniq...