Method and apparatus for serializing access to multithreading unsafe resources

• US 5,630,136 A
• Filed: 06/09/1995
• Issued: 05/13/1997
• Est. Priority Date: 06/09/1995
• Status: Expired due to Fees

• Current Assignee: Sun Microsystems Incorporated (Oracle Corporation)
• Original Assignee: Sun Microsystems Incorporated (Oracle Corporation)
• Inventors: Davidson, Andrew E., Snyder, Alan, Balick, Maurice
• Primary Examiner(s): Kriess, Kevin A.
• Assistant Examiner(s): Banankhah, Majid A.
• Application Number:
  US08/494,117
• Time in Patent Office: 704 Days
• Field of Search: 395/700, 395/650, 395/670, 395/676, 395/677, 364/DIG. 1
• US Class Current: 718/106
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms

Abstract

An improved technique for serializing access to multithreading unsafe resources is described. A baton manager is used to manage the serializing of accesses to a multithreading unsafe resource. For a thread to access the multithreading unsafe resource, the thread must first obtain a baton from the baton manager. Then, once the thread has finished accessing the multithreading unsafe resource, the thread releases the baton to the baton manager. Hence, by using the baton manager to manage the baton, accesses to multithreading unsafe resources are serialized while program crashes or deadlocks are minimized. The multithreading unsafe resource will typically have a plurality of baton objects associated therewith. The baton objects are objects of object-oriented programming. The baton manager will permit at most one of the baton objects for a given multithreading unsafe resource to own the baton at a time. The threads associated with the baton objects waiting to own the baton must wait until they receive the baton before they can access the multithreading unsafe resource.

Claims

1. A computer-implemented method for synchronizing multithreaded processes within a multitasking computer system so that multiple threads can safely access a multithreading unsafe resource, said method comprising the computer-implemented steps of:

(a) creating a baton object for each thread that desires access to a multithreading unsafe resource, each of the baton objects contending for a baton associated with the multithreading unsafe resource, wherein the multithreading unsafe resource may only be accessed by a particular thread when such thread'"'"'s associated baton object holds the baton;

(b) causing a first one of the baton objects to hold the baton before the thread associated with the first baton object is permitted to access the multithreading unsafe resource;

(c) subsequent to said causing step (b), permitting the thread associated with the first baton object to access the multithreading unsafe resource; and

(d) releasing the baton from the baton object once the access by the thread associated with the first baton object is completed,

whereby when the first baton object holds the baton, other baton objects are prevented from holding the baton and their associated threads are prevented from accessing the multithreading unsafe resource.

2. A method as recited in claim 1, wherein said causing step (b) comprises determining whether the baton for the multithreading unsafe resource is already held by the baton object.

3. A method as recited in claim 1, wherein said causing step (b) comprises determining whether the baton object associated with a current thread holds the baton for the multithreading unsafe resource.

4. A method as recited in claim 1, wherein said causing step (b) comprises:

(b1) determining whether the baton for the multithreading unsafe resource is already held by the baton object; and

(b2) determining whether at least one baton object associated with a current thread holds the baton for the multithreading unsafe resource, and

wherein when neither the baton is already held by the baton object nor the at least one baton object associated with the current thread holds the baton, said causing step (b) further comprises;

(b3) obtaining an access lock for the multithreading unsafe resource;

(b4) setting a baton held flag for the baton object to indicate ownership of the baton by the baton object; and

(b5) storing an identifier for the current thread in a baton holder variable to indicate the thread holding the baton.

5. A method as recited in claim 1, wherein the multithreading unsafe resource comprises a multithreading unsafe algorithm.

6. A method as recited in claim 1, wherein the multithreading unsafe resource comprises a multithreading unsafe library.

7. A method as recited in claim 1, wherein the multithreading unsafe resource comprises a multithreading unsafe function.

24. A method as recited in claim 1, further comprising the step of destroying the baton object subsequent to release of the baton from the baton object.

8. A computer-implemented method for synchronizing multithreaded processes so that multiple threads can safely access a multithreading unsafe algorithm, said method comprising the computer-implemented steps of:

(a) creating baton objects for each thread desiring access to a multithreading unsafe algorithm, each of the baton objects contending for a baton associated with the multithreading unsafe algorithm;

(b) before one of the threads calls the multithreading unsafe algorithm, requiring the baton object associated with the one of the threads to grab the baton associated with the multithreading unsafe algorithm;

(c) subsequent to said requiring step (b), permitting the thread associated with the baton object holding the baton to call the multithreading unsafe algorithm, wherein the multithreading unsafe algorithm may only be called by a particular thread when such thread'"'"'s associated baton object holds the baton;

(d) returning from the multithreading unsafe algorithm; and

(e) subsequent to said returning step (d), releasing the baton from the baton object that grabbed the baton in step (b); and

whereby when a particular baton object holds the baton, other baton objects are prevented from holding the baton and the threads associated with the baton object that are prevented from holding the baton are prevented from accessing the multithreading unsafe algorithm.

9. A method as recited in claim 8, wherein said requiring step (b) comprises the step of determining whether the baton for the multithreading unsafe algorithm is already held by the baton object.

10. A method as recited in claim 8, wherein said requiring step (b) comprises the step of determining whether the baton object associated with a current thread holds the baton for the multithreading unsafe algorithm.

11. A method as recited in claim 8, wherein said requiring step (b) comprises the steps of:

(b1) determining whether the baton for the multithreading unsafe algorithm is already held by the baton object; and

(b2) determining whether at least one baton object associated with the current thread holds the baton for the multithreading unsafe algorithm, and

wherein when neither the baton is already held by the baton object nor the at least one baton object associated with the current thread holds the baton, said requiring step (b) further comprises;

(b3) obtaining an access lock for the multithreading unsafe algorithm.

12. A method as recited in claim 11, wherein said requiring step (b) further comprises:

(b4) setting a baton held flag for the baton object to indicate ownership of the baton object; and

(b5) storing an identifier for the current thread in a baton holder variable to indicate the thread holding the baton.

13. A method as recited in claim 8, wherein the multitasking computer system operates a X_-- Windows System environment, the X_-- Windows System environment having an X_-- Server and a plurality of objects.

14. A method as recited in claim 13, wherein said method further comprises the step of (e) initializing the baton objects for an X_-- Windows System.

15. A method as recited in claim 13, wherein said method further comprises the step of (e) utilizing a baton event loop to receive incoming event from the X_-- Server and distribute the events to the objects, wherein the baton event loop executes within one of the threads and one of the baton objects is associated therewith.

16. A method as recited in claim 8, wherein the multitasking computer system operates a windows system environment, the windows system environment having a server and a plurality of objects, and

wherein said method further comprises the step of (e) utilizing a baton event loop to receive incoming event from the server and distribute the events to the objects, wherein the baton event loop executes within one of the threads and one of the baton objects is associated therewith.

17. A method as recited in claim 16, wherein the baton is held by the baton object associated with the baton event loop only during a critical section of the baton event loop, thereby allowing the baton objects associated with other of the threads to grab the baton without deadlock or substantial delay.

18. A method as recited in claim 16, wherein said method further comprises:

(f) maintaining a list of connections, and wherein said utilizing step (e) comprises the steps of;

obtaining the baton by the baton object associated with the thread executing the baton event loop;

distributing the incoming events which have been received;

releasing the baton by the baton object associated with the thread executing the baton event loop;

blocking the thread executing the baton event loop; and

using a poll command on the list of connections to wake-up the thread executing the baton event loop when information is present for one of the connections within the list of connections.

25. A method as recited in claim 8, further comprising the step of destroying the baton object subsequent to release of the baton from the baton object.

19. An apparatus for serializing access to a multithreading unsafe resource, said apparatus comprising:

executable computer code including access requests to the multithreading unsafe resource;

a computer system and an operating system which both support multithreading, said computer system in conjunction with said operating system being arranged to execute said executable computer code in a multithreaded manner; and

a baton manager, operatively connected to said computer system and said operating system and the multithreading unsafe resource, for serializing access of the multithreading unsafe resource by said computer system and said operating system during the execution of said executable computer code so that at any given point in time only a single thread accesses the multithreading unsafe resource, wherein said baton manager uses at least one baton object to manage ownership of a mutually exclusive lock, the baton objects being associated with at most one thread and the mutually exclusive lock being arranged to insure that the accesses to the multithreading unsafe resource are serialized.

20. An apparatus as recited in claim 19, wherein said baton manager manages multiple baton objects for the multithreading unsafe resource, with at most only one of the baton objects associated with the multithreading unsafe resource owning the mutually exclusive lock during execution of said executable computer code.

21. An apparatus as recited in claim 19, wherein said apparatus serializing access to a plurality of multithreading unsafe resources,

wherein said baton manager includes a mutually exclusive lock for each of the multithreading unsafe resources, and

wherein said baton manager manages multiple baton objects for each of the multithreading unsafe resources, with at most only one of the baton objects associated with each of the multithreading unsafe resources owning the mutually exclusive lock corresponding thereto during execution of said executable computer code.

26. An apparatus as recited in claim 19, wherein each baton object is configured such that it is associated with only a single thread.

22. A computer program product, comprising:

a computer usable medium having computer readable code embodied therein for serializing access to multithreading unsafe resources, and wherein said computer readable code comprises;

first computer readable program code devices configured to cause a computer to effect creating a baton object associated with at most one thread, the baton object being configured to facilitate accessing a multithreading unsafe resource wherein the multithreading unsafe resource may only be accessed by the thread associated with the baton object when the baton object holds the baton;

second computer readable program code devices configured to cause a computer to effect grabbing a baton by the baton object before accessing the multithreading unsafe resource;

third computer readable program code devices configured to cause a computer to effect accessing the multithreading unsafe resource; and

fourth computer readable program code devices configured to cause a computer to effect releasing the baton from the baton object after the accessing of the multithreading unsafe resource is complete; and

whereby when the baton object holds the baton, threads not associated with the baton object are prevented from accessing the multithreading unsafe resource.

23. A computer program product as recited in claim 22,

wherein said second computer readable program code devices comprises:

fifth computer readable program code devices to determine whether the baton object associated with the current thread holds the baton for the multithreading unsafe resource; and

sixth computer readable program code devices to obtain an access lock for the multithreading unsafe resource.

27. A computer program product as recited in claim 22, wherein said computer readable code further comprises seventh computer readable program code devices configured to destroy the baton object after the accessing of the multithreading unsafe resource is complete.