System and method for adding highly optimized synchronization capability to objects at run-time

• US 6,237,043 B1
• Filed: 11/19/1997
• Issued: 05/22/2001
• Est. Priority Date: 11/19/1997
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Kilpatrick, Paul Jerome, Brown, Michael Wayne, Lawrence, Kelvin Roderick, Gu, Weiming, Collins, Michael Thomas
• Primary Examiner(s): COURTENAY III, ST JOHN
• Application Number:
  US08/974,751
• Time in Patent Office: 1,280 Days
• Field of Search: 709/300, 709/303, 709/1, 709/104, 709/106, 709/310-332, 710/200, 710/220, 710/240-244, 711/170-172
• US Class Current: 719/316
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Abstract

The present invention is directed to a system, method, and computer-readable medium for providing a highly efficient locking mechanism for an object'"'"'s shared data. The locking mechanism is bound to an object during program execution (i.e. during run-time) when synchronization is first requested for the object'"'"'s shared data. Thus, there are no changes to the actual code, either source code or binary code, which defines the object. A locking mechanism is bound to an object by defining a memory area within the object'"'"'s header, which either contains the locking mechanism or a pointer to a locking mechanism. The locking mechanism remains bound to the object for the life of the object. Efficiency is gained by limiting the use of operating system semaphores (i.e. kernel semaphores). Operating system semaphores are not used unless blocking (i.e. contention) occurs. Rather, the locking mechanism bound to the object is used during non-blocking situations. Additional efficiency is gained by not assigning or initializing an object'"'"'s locking mechanism until the first synchronization request is received for the object'"'"'s shared data. In one embodiment of the present invention, the object'"'"'s header memory area contains the actual locking mechanism. In another embodiment of the present invention, the object'"'"'s header memory area contains a pointer or index to a locking mechanism.

Claims

1. A method of synchronizing object data in an object-oriented, run-time environment, comprising the steps of:

creating an object, wherein the object includes a header area and a data area;

receiving one or more requests, each from a requester, for synchronized access to the object'"'"'s data, wherein the object'"'"'s data is stored in the data area;

binding a locking mechanism to the object when a first request is received, wherein said binding step includes the step of storing the locking mechanism in the header area of the object; and

controlling access to the object'"'"'s data through the bound locking mechanism.

2. A method according to claim 1, wherein said creating step further comprises the step of allocating additional memory in the header area of the object when the object is created, and wherein said storing step comprises the step of storing the locking mechanism in the additional memory.

3. A method according to claim 1, wherein said binding step comprises the steps of:

selecting a next available locking mechanism from a plurality of locking mechanisms; and

storing a pointer to the selected locking mechanism in the header area of the object.

4. A method according to claim 1, wherein said controlling step comprises the step of deciding whether to grant access to the object'"'"'s data to a current requestor.

5. A method according to claim 1, wherein the header area and the data area are stored in a heap memory.

6. A method according to claim 5, wherein said creating step further comprises the step of allocating additional memory in the header area of the object when the object is created, and wherein said storing step comprises the step of storing the pointer to the selected locking mechanism in the additional memory.

7. A method according to claim 4, wherein said deciding step comprises the steps of:

determining if the object is in a locked state; and

if the object is not in a locked state, granting the synchronized access to the current requestor.

8. A method according to claim 7, wherein said granting step further comprises the step of setting the object to a locked state.

9. A method according to claim 7, wherein said deciding step further comprises the steps of:

if the object is in the locked state, determining a lock owner; and

if the lock owner is equal to the current requester, granting the synchronized access to the current requester.

10. A method according to claim 9, further comprising the steps of:

if the lock owner is not equal to the current requestor, denying access to the current requestor; and

if access is denied to the current requester, putting the current requester in a wait state to wait for access to the object.

11. An information handling system, comprising:

a plurality of objects, each object including a header area and a data area;

means for requesting synchronized access to a desired object'"'"'s data;

means for binding a locking mechanism to the desired object when a first request is received, wherein said means for binding includes means for storing the locking mechanism in the header area of the desired object; and

means for controlling access to the object'"'"'s data through the bound locking mechanism.

12. An information handling system according to claim 11, further comprising means for allocating additional memory in the header area of each object when the object is created, and wherein said means for storing comprises means for storing the locking mechanism in the additional memory of the desired object.

13. An information handling system according to claim 11, wherein said means for controlling comprises means for deciding whether to grant access to the desired object'"'"'s data to a current requester.

14. An information handling system according to claim 11, wherein the header area and the data area are stored in a heap memory.

15. An information handling system according to claim 14, further comprising a plurality of locking mechanisms, and wherein said means for binding comprises:

means for selecting a next available locking mechanism from the plurality of locking mechanisms; and

means for storing a pointer to the selected locking mechanism in the header area of the desired object.

16. An information handling system according to claim 13, wherein said means for deciding comprises:

means for determining if the desired object is in a locked state; and

means for granting the synchronized access to the current requestor.

17. An information handling system according to claim 15, further comprising means for allocating additional memory in the header area of each object when the object is created, and wherein said means for storing comprises means for storing the pointer to the selected locking mechanism in the additional memory of the desired object.

18. An information handling system according to claim 16, wherein said means for granting further comprises means for setting the desired object to a locked state.

19. An information handling system according to claim 16, wherein said means for deciding further comprises means for determining a lock owner.

20. An information handling system according to claim 19, further comprising:

means for denying access to the current requester; and

means for putting the current requestor in a wait state to wait for access to the desired object.

21. A computer readable medium, comprising:

a plurality of objects, each object including a header area and a data area;

means for requesting synchronized access to a desired object'"'"'s data;

means for binding a locking mechanism to the desired object when a first request is received, wherein said means for binding includes means for storing the locking mechanism in the header area of the desired object; and

means for controlling access to the desired object'"'"'s data through the bound locking mechanism.

22. A computer readable medium according to claim 21, further comprising means for allocating additional memory in the header area of each object when the object is created, and wherein said means for storing comprises means for storing the locking mechanism in the additional memory of the desired object.

23. A computer readable medium according to claim 21, wherein said means for binding comprises:

means for selecting a next available locking mechanism from a plurality of locking mechanisms; and

means for storing a pointer to the selected locking mechanism in a header area of the desired object.

24. A computer readable medium according to claim 21, wherein said means for controlling comprises means for deciding whether to grant access to the desired object'"'"'s data to a current requester.

25. A computer readable medium according to claim 21, wherein the header area and the data area are stored in a heap memory.

26. A computer readable medium according to claim 23, further comprising means for allocating additional memory in the header area of each object when the object is created, and wherein said means for storing comprises means for storing the pointer to the selected locking mechanism in the additional memory of the desired object.

27. A computer readable medium according to claim 24, wherein said means for deciding comprises:

means for determining if the desired object is in a locked state; and

means for granting the synchronized access to the current requester.

28. A computer readable medium according to claim 27, wherein said means for granting access further comprises means for setting the desired object to a locked state.

29. A computer readable medium according to claim 27, wherein said means for deciding further comprises means for determining a lock owner.

30. A computer readable medium according to claim 29, further comprising:

means for denying access to the current requestor; and

means for putting the current requester in a wait state to wait for access to the object.