Method and apparatus to provide concurrency control over objects without atomic operations on non-shared objects

• US 6,772,153 B1
• Filed: 08/11/2000
• Issued: 08/03/2004
• Est. Priority Date: 08/11/2000
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Bacon, David F., Fink, Stephen
• Primary Examiner(s): Robinson, Greta
• Assistant Examiner(s): DODDS, HAROLD E
• Application Number:
  US09/636,718
• Time in Patent Office: 1,453 Days
• Field of Search: 707/1, 707/3, 707/8, 707/9, 707/100, 707/103, 707/200, 707/215, 707/206, 707/205, 709/100, 709/103, 709/104, 709/310, 709/313, 709/315, 709/102, 710/200
• US Class Current: 1/1
• CPC Class Codes: G06F 2209/523 Mode
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms
• CPC Class Codes: Y10S 707/99938 Concurrency, e.g. lock management in shared database

Abstract

A lock is implemented by assigning the lock to a thread that creates the associated object. The “owning thread” can thereafter acquire and release the lock without any atomic operations. If another thread attempts to acquire the lock, the non-owning thread sends a message to the owning thread, requesting permission to acquire the lock. At some point, the owning thread receives the message from the non-owning thread and changes the state of the lock such that future lock/unlock operations use atomic operations that support object sharing.

Claims

1. A data processing system comprised of:

at least one data processor and a memory, said memory for storing threads and objects created by threads, and further comprising a lock that is implemented by assigning the lock to a first thread that creates an associated object, wherein the first thread to which the lock is assigned is enabled to acquire and release the lock without requiring the use of an atomic operation wherein, in response to a second thread attempting to acquire the lock to the associated object, the second thread sends a message to the first thread, the message requesting permission to acquire the lock.

2. A data processing system as in claim 1 wherein, in response to receiving the message, the first thread changes the state of the lock such that future lock/unlock operations are performed using atomic operations that support object sharing.

3. A data processing system as in claim 1 wherein said lock is comprised of a first field for indicating a shared/not shared status of the associated object, a second field for indicating a locked/unlocked status of the associated object, and a third field for storing an identification of the thread to which the lock is assigned.

4. A method for managing locks in a data processing system, comprising steps of:

upon an occurrence of a thread T creating an object O, setting a lock word to indicate that O is unlocked, non-shared, and owned by T;

thereafter enabling T, that owns object O, to acquire and release O without requiring atomic operations;

if T attempts to acquire a non-shared object O(ns) that T does not own, sending a message from T to the owner thread T(o) of O(ns), the message requesting that O(ns) be changed to a shared object O(s);

in response to the message, changing the lock word for O(ns) to indicate O(s); and

thereafter, performing all lock operations on O(s) through atomic system locking operations.

5. A method as in claim 4, wherein said lock word is comprised of a first field for indicating a shared/not shared status of the associated object, a second field for indicating a locked/unlocked status of the associated object, and a third field for storing an identification of the thread to which the lock is assigned.

6. A method as in claim 4, wherein each thread T periodically polls for incoming messages to ensure that all lock change requests are handled in a timely manner.

7. A method as in claim 4, wherein in response to the message, the method further comprises steps of:

creating a system lock;

if the object is already locked, locking the system lock;

setting the lock word to indicate that the object is shared;

storing an identification of the system lock into the lock word; and

sending an acknowledgement message to the thread T that requested that O(ns) be changed to the shared object O(s).

8. A method as in claim 4, wherein said lock word is comprised of a first field for indicating a shared/not shared status of the associated object, a second field for indicating a locked/unlocked status of the associated object, and a third field for storing, when the first field indicates the not shared status of the associated object, an identification of the thread to which the lock is assigned, or when the first field indicates the shared status of the associated object, an identification of a corresponding system lock.

9. A computer program embodied on computer-readable medium, the computer program being operable for implementing a method for managing locks in a data processing system wherein threads execute, the method implemented by the computer program comprising steps of:

upon an occurrence of a thread T creating an object O, setting a lock word in a memory of the data processing system to indicate that O is unlocked, non-shared, and owned by T, T thereafter acquiring and releasing O without requiring atomic, system locking operations;

if T attempts to acquire a non-shared object O(ns) that T does not own, sending a message from T to the owner thread T(o) of O(ns), the message requesting that O(ns) be changed to a shared object O(s);

in response to the message, changing the lock word for O(ns) to indicate O(s); and

thereafter, performing all lock operations on O(s) through atomic, system locking operations.

10. A computer program as in claim 9, wherein said lock word is comprised of a first field for indicating a shared/not shared status of the associated object, a second field for indicating a locked/unlocked status of the associated object, and a third field for storing, when the first field indicates the not shared status of the associated object, an identification of the thread to which the lock is assigned, or when the first field indicates the shared status of the associated object, an identification of a corresponding system lock.

11. A computer program as in claim 9, wherein each thread T periodically polls for incoming messages to ensure that all lock change requests are handled in a timely manner.

12. A computer program as in claim 9, wherein in response to the message, the method implemented by the computer program further comprises steps of:

creating a system lock;

if the object is already locked, locking the system lock;

setting the lock word to indicate that the object is shared;

storing an identification of the system lock into the lock word; and

sending an acknowledgement message to the thread T that requested that O(ns) be changed to the shared object O(s).