Method and apparatus for coordination of a shared object in a distributed system

• US 6,141,720 A
• Filed: 06/12/1997
• Issued: 10/31/2000
• Est. Priority Date: 06/12/1997
• Status: Expired due to Term

• Current Assignee: Computer Associates Think Inc. (Broadcom, Inc.)
• Original Assignee: Cabletron Systems Incorporated (Extreme Networks, Inc.)
• Inventors: Jeffords, Jason, Crowley, Todd, Sexton, Donald, Hazel, Thomas
• Primary Examiner(s): Etienne, Ario
• Application Number:
  US08/873,550
• Time in Patent Office: 1,237 Days
• Field of Search: 710/200, 710/108, 710/36, 710/39, 710/40, 710/112, 710/240, 710/244, 710/220
• US Class Current: 710/200
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Abstract

Method and apparatus for coordinating access to a shared object amongst a plurality of processes in a distributed system. One process is identified as a lock owner process controlling a lock associated with the shared object. When a process needs to access the shared object, it requests control of the lock from the lock owner process. When no other process controls the lock, the lock owner process grants control to the requesting process. When another process controls the lock, the lock owner process places the requesting process in a queue and waits for the lock to become available. All accesses to the shared object are processed through the lock owner processes thus assuring coordination and synchronization among the processes.

Claims

1. A computer-implemented method of controlling access to an object shared amongst a plurality of processes in a distributed system, the method comprising steps of:

(a) assigning one process as an owner of a lock associated with the shared object;

(b) when a process requires access to the shared object, the process requesting the lock from the lock owner process;

(c) when the lock owner process receives the lock request, the lock owner process determining whether or not any process has control of the lock by sending a request to all processes inquiring if a process currently controls the lock associated with the shared object; and

(d) when the lock owner process determines that no process has control of the lock, the lock owner process granting control of the lock to the requesting process.

2. The method as recited in claim 1, wherein step (c) includes a step of:

the lock owner process determining whether or not the lock owner process is currently accessing the shared object associated with the lock.

3. The method as recited in claim 1, wherein:

when a first requesting process has been granted control of the lock, the first requesting process sending a message to the lock owner process when the first requesting process no longer requires access to the shared object.

4. The method as recited in claim 3, wherein:

when a second requesting process sends a second lock request message to the lock owner process and the first requesting process has not sent a lock release message to the lock owner process, the lock owner process placing the second requesting process in a queue; and

when the first requesting process sends the lock release message to the lock owner process, the lock owner process accessing the queue and granting control of the lock to the next requesting process in the queue.

5. The method as recited in claim 4, wherein the queue operates on a first-in, first-out basis.

6. The method as recited in claim 4, wherein the queue is a priority queue in that the next requesting process is that requesting process having a priority higher than any other requesting process in the queue.

7. The method as recited in claim 3, wherein:

when the lock owner process receives the lock release message from the first requesting process, the lock owner process determining whether there are any processes in the queue.

8. The method as recited in claim 1, including a step of:

the lock owner process placing the requesting process in a queue of processes waiting to receive control of the lock.

9. The method as recited in claim 8, further including a step of the lock owner process placing the requesting process in the queue according to a priority level assigned to each requesting process;

wherein a first requesting process in the queue with a priority level higher than a priority level of a second requesting process in the queue will be granted the lock first.

10. The method as recited in claim 8, wherein:

when the lock owner process has granted control to a first requesting process, the lock owner process waiting for a lock release message from the first requesting process; and

when the lock owner process has received the lock release message, the lock owner process retrieving a next requesting process from the queue and granting control of the lock to the retrieved process.

11. The method as recited in claim 8, wherein step (c) includes a step of:

the lock owner process determining if a process is stored in the queue.

12. The method as recited in claim 1, wherein step (c) comprises:

the lock owner process waiting to receive a negative response from each other processes prior to granting control of the lock to the requesting process.

13. The method as recited in claim 12, wherein step (c) further comprises:

the lock owner process denying the control of the lock to the requesting process when a positive response is received from another process.

18. The method as recited in claim 1, wherein:

when the lock owner process fails, a new lock owner is chosen from amongst the remaining processes in the plurality of processes.

14. An apparatus for controlling access to an object shared amongst a plurality of processes in a distributed system, the apparatus comprising:

means for assigning one process as an owner of a lock associated with the shared object;

means for requesting the lock from the lock owner process when a process requires access to the shared object;

means for determining whether or not any process has control of the lock when the lock owner process receives the lock request including means for sending a request from the lock owner process to all processes inquiring if a process currently controls the lock associated with the shared object; and

means for granting control of the lock to a requesting process when the lock owner determines that no process has control of the lock.

15. The apparatus as recited in claim 14, further comprising:

means for releasing the lock back to the lock owner process when the requesting process, to which the lock owner process had granted control, no longer requires the lock.

16. The apparatus as recited in claim 14, wherein the granting means comprises:

means for placing the requesting process in a queue when the lock owner process determines that a p process has control of the lock.

17. The apparatus as recited in claim 16, wherein the granting control means comprise:

means for retrieving a next requesting process from the queue and granting control of the lock to the next requesting process.

19. The apparatus as recited in claim 14, further comprising:

means for choosing a new lock owner process when the current lock owner process fails, the new lock owner process chosen from amongst the remaining processes in the plurality of processes.