Computer-implemented system and method for lock handling

• US 7,380,073 B2
• Filed: 11/26/2003
• Issued: 05/27/2008
• Est. Priority Date: 11/26/2003
• Status: Active Grant

• Current Assignee: SAS Institute Incorporated
• Original Assignee: SAS Institute Incorporated
• Inventors: Shorb, Charles S.
• Primary Examiner(s): Kim; Matthew
• Assistant Examiner(s): TSAI, SHENG JEN
• Application Number:
  US10/722,761
• Publication Number:
  US 20050114609A1
• Time in Patent Office: 1,644 Days
• Field of Search: 711/152, 711/150
• US Class Current: 711/152
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms

Abstract

Computer-implemented systems and methods for handling access to one or more resources. Executable entities that are running substantially concurrently provide access requests to an operating system (OS). One or more traps of the OS are avoided to improve resource accessing performance through use of information stored in a shared locking mechanism. The shared locking mechanism indicates the overall state of the locking process, such as the number of processes waiting to retrieve data from a resource and/or whether a writer process is waiting to access the resource.

Claims

1. A memory for storing a computer-implemented shared locking data store for handling multiple executable entities'"'"' access to at least one resource, said shared locking data store being stored in a computer memory, said shared locking data store comprising:

write requested data that is indicative of when a write request for the resource has been made;

writer active data that is indicative of whether a writer process is actively undergoing a write operation with respect to the resource;

wait event posted data, wherein the wait event posted data is indicative of whether a read request to the resource has completed, wherein the wait event posted data is used to indicate when a write request can access the resource;

reader data that is indicative of whether a reader process is active and attempting to read from the resource;

wherein the shared locking data store allows writer and reader locking state information to be determined so that access to the resource can be handled;

wherein encapsulation of both lock status data and the reader data in the shared locking data store allows a hardware atomic operation to operate upon both the lock status data and the reader data as a single unit for determining how access to the resource is to be handled;

wherein the multiple executable entities'"'"' access is a concurrent access to the at least one resource;

wherein a set status for the write requested data indicates whether an operating system (OS) mutex lock is to be used for processing access to the resource and is used to avoid an OS mutex lock when no writer process is pending.

2. The memory for storing the shared locking data store of claim 1, wherein the executable entities include processes, threads, daemons, applets, servlets, ActiveX components, stand-alone applications, code that runs at the request of another program, or combinations thereof;

wherein use of the shared locking data stores allows for the avoidance of an operating system call or avoidance of a resource accessing trap of the operating system'"'"'s kernel.

3. The memory for storing the shared locking data store of claim 1, wherein the multiple executable entities include threads which are to access the resource, wherein the threads comprise a writer thread and a reader thread, wherein the locking state information is used to determine how the writer thread and the reader thread access the resource.

4. The memory for storing the shared locking data store of claim 3, wherein the resource requires protection on a per thread basis.

5. The memory for storing the shared locking data store of claim 3, wherein the locking state information indicates where in the overall locking process an operating system is with respect to the resource.

6. The memory for storing the shared locking data store of claim 3, wherein the request of the reader thread is allowed to succeed unless there is a write request active or pending as indicated by the write requested data and the writer active data.

7. The memory for storing the shared locking data store of claim 3 further comprising:

rules mechanism that indicates how resource access requests are to be handled based upon the data stored in the shared locking data store.

8. The memory for storing the shared locking data store of claim 7, wherein the rules mechanism includes allowing any number of read requests to succeed unless there is a writer active or pending as indicated by the shared locking data store.

9. The memory for storing the shared locking data store of claim 8, wherein the rules mechanism includes allowing only one writer to be active at any given time.

10. The memory for storing the shared locking data store of claim 9, wherein the rules mechanism includes that no preference is given when deciding which of waiting read or write requests should be honored first.

11. The memory for storing the shared locking data store of claim 10, wherein the rules mechanism substantially eliminates a reader request starvation or a writer request starvation situation with respect to the resource.

12. The memory for storing the shared locking data store of claim 1, wherein the resource comprises data stored in computer memory.

13. The memory for storing the shared locking data store of claim 1, wherein the resource comprises a computer file.

14. The memory for storing the shared locking data store of claim 1, wherein the resource comprises an input/output device.

15. The memory for storing the shared locking data store of claim 1, wherein the write requested data is to have a set status when a write request has been made.

16. The memory for storing the shared locking data store of claim 1, wherein the operating system returns a lock busy status indicator when a lock cannot be obtained within a predetermined time.

17. The memory for storing the shared locking data store of claim 1, wherein indication of whether a writer process is active by the writer active data is used to protect against readers posting an operating system (OS) event after the writer thread has been activated.

18. The memory for storing the shared locking data store of claim 1 further comprising wait event posted data, wherein the wait event posted data is indicative of whether a read request to the resource has completed, wherein the wait event posted data is used to indicate when a write request can access the resource, wherein a last active read clears status of the wait event posted data prior to posting an event.

19. The memory for storing the shared locking data store of claim 18, wherein the clearing ensures that one and only one posting to a writer of an event occurs.

20. The memory for storing the shared locking data store of claim 19, wherein the posting occurs if status of the writer active data is not set.

21. The memory for storing the shared locking data store of claim 18, wherein the processes comprise threads, wherein the wait event posted data indicates when events can be posted by one thread to notify another thread that the other thread'"'"'s request can be processed.

22. The memory for storing the shared locking data store of claim 21, wherein the wait event posted data indicates whether a reader thread can post a lock release event to a writer thread.

23. The memory for storing the shared locking data store of claim 22, wherein the wait event posted data is used to prevent multiple reader threads from posting redundant lock release events.

24. The memory for storing the shared locking data store of claim 18, wherein the write requested data, writer active data, and wait event posted data provide multi-threaded protection in place of an operating system (OS) mutex.

25. The memory for storing the shared locking data store of claim 18, wherein locking state data comprises the write requested data, the writer active data, the reader count data, and the wait event posted data;

wherein the locking state data is formatted as a single atomic unit.

26. The memory for storing the shared locking data store of claim 25, wherein the locking state data is formatted as a multi-bit single unit.

27. The memory for storing the shared locking data store of claim 26, wherein the formatting of the locking state data as a single unit allows an operating system to use atomic operations upon the locking state data.

28. The memory for storing the shared locking data store of claim 27, wherein the atomic operations include an atomic get operation.

29. The memory for storing the shared locking data store of claim 27, wherein the atomic operations include an atomic set operation.

30. The memory for storing the shared locking data store of claim 27, wherein the atomic operations include an atomic add operation.

31. The memory for storing the shared locking data store of claim 27, wherein the atomic operations include an atomic sub operation.

32. The memory for storing the shared locking data store of claim 25, wherein the locking state data is formatted as a multi-bit single unit;

wherein the write requested data comprises a single bit in the unit;

wherein the writer active data comprises a single bit in the unit;

wherein the wait event posted data comprises a single bit in the unit;

wherein the reader data comprises a plurality of bits in the unit to indicate number of active readers with respect to the resource.

33. The memory for storing the shared locking data store of claim 32, wherein the reader data comprises low order bits of the unit.

34. The memory for storing the shared locking data store of claim 33, wherein the reader data'"'"'s count of the readers provides an indication as to whether readers are present and when the last reader exits.

35. The memory for storing the shared locking data store of claim 32, wherein a read lock acquisition means accesses the locking state data for processing a read lock acquisition of the resource.

36. The memory for storing the shared locking data store of claim 32, wherein a read lock release means accesses the locking state data for processing a read lock release of the resource.

37. The memory for storing the shared locking data store of claim 32, wherein a write lock acquisition means accesses the locking state data for processing a write lock acquisition of the resource.

38. The memory for storing the shared locking data store of claim 32, wherein a write lock release means accesses the locking state data for processing a write lock release of the resource.

39. The memory for storing the shared locking data store of claim 1, wherein the hardware atomic operation includes machine level instructions for performing an operation on the shared locking data store for handling access to the resource;

wherein the reader data includes reader count data;

wherein the encapsulation of both the lock status data and the reader count data in the shared locking data store include encapsulation of status bits and bits which form an integer subset containing the count of reader requests that have been granted and that need to be processed;

wherein the status bits include a write pending-requested indicator that is set when a write request has been made in order to determine whether an OS mutex lock is required.

40. A computer-implemented method for handling multiple executable entities'"'"' access to at least one resource, comprising:

receiving a request from an executable entity to access a resource;

determining how to process the resource request based upon lock state data;

wherein lock state data comprises write requested data and reader data;

wherein the write requested data is indicative of when a write request for the resource has been made with respect to the resource;

wherein if the write requested data indicates that a write request has not been made for the resource, then providing access to the resource such that an operating system (OS) mutex is avoided for a read lock acquisition;

wherein the reader data is indicative of whether a reader executable entity is active and attempting to read from the resource;

wherein encapsulation of both lock status data and the reader data in the shared locking data store allows a hardware atomic operation to operate upon both the lock status data and the reader data as a single unit for determining how access to the at least one resource is to be handled;

wherein the multiple executable entities'"'"' access is a concurrent access to the at least one resource;

wherein a set status for the write reauested data indicates whether an operating system (OS) mutex lock is to be used for processing access to the resource and is used to avoid an OS mutex lock when no writer process is pending.

41. A computer-implemented apparatus for handling multiple executable entities'"'"' access to at least one resource, comprising:

means for receiving a request from an executable entity to access a resource;

means for determining how to process the resource request based upon lock state data;

wherein lock state data comprises write requested data and reader data,

wherein the write requested data is indicative of when a write request for resource has been made with respect to the resource;

wherein if the write requested data indicates that a write request has not been made, then providing access to the resource such that an operating system (OS) mutex is avoided for a read lock acquisition;

wherein the reader data is indicative of whether a reader executable enity is active and attempting to read from the resource;

wherein encapsulation of both lock status data and the reader data in the shared locking data store allows a hardware atomic operation to operate upon both the lock status data and the reader data as a single unit for determining how access to the at least one resource is to be handled;

wherein the multiple executable entities'"'"' access is a concurrent access to the at least one resouce;

wherein a set status for the write requested data indicates whether an operating system (OS) mutex lock is to be used for processing access to the resource and is used to avoid an OS mutex lock when no writer process is pending.

42. The apparatus of claim 41 further comprising:

read lock acquisition means for accessing the lock state data in order to process a read lock acquisition of the resource;

read lock release means for accessing the lock state data in order to process a read lock release of the resource;

write lock acquisition means for accessing the lock state data in order to process a write lock acquisition of the resource;

write lock release means for accessing the lock state data in order to process a write lock release of the resource.

43. A machine-readable medium or media storing software instructions for handling multiple executable entities'"'"' access to at least one resource, said software instructions, when executed by a machine, cause the machine to:

receiving a request from an executable entity to access a resource;

determining how to process the resource request based upon lock state data;

wherein lock state data comprises write requested data and reader data;

wherein the write requested data is indicative of when a write request for the resource has been made with respect to the resource;

wherein if the write requested data indicates that a write request has not been made for the resource, then providing access to the resource such that an operating system (OS) mutex is avoided for a read lock acquisition;

wherein the reader data is indicative of whether a reader executable entity is active and attempting to read from the resource;

wherein encapsulation of both lock status data and the reader data in the shared locking data store allows a hardware atomic operation to operate upon both the lock status data and the reader data as a single unit for determining how access to the at least one resource is to be handled

wherein the multiple executable entities'"'"' access is a concurrent access to the at least one resource;

wherein a set status for the write requested data indicates whether an operating system (OS) mutex lock is to be used for processing access to the resource and is used to avoid an OS mutex lock when no writer process is pending.