Computer-implemented system and method for lock handling

• US 7,594,091 B2
• Filed: 05/23/2008
• Issued: 09/22/2009
• 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): TSAI, SHENG JEN
• Application Number:
  US12/126,177
• Publication Number:
  US 20080222331A1
• Time in Patent Office: 487 Days
• Field of Search: 711/200, 711/152
• US Class Current: 711/200
• 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 may be 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 may be handled;

wherein the write requested data has a set status when a write request has been made, wherein the set status indicates whether a mutex lock is to be used for processing access to the resource, wherein the set status is set to indicate that the mutex lock is not to be used if no write request is pending.

2. The memory 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 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 of claim 3, wherein the resource requires protection on a per thread basis.

5. The memory 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 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 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 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 of claim 8, wherein the rules mechanism includes allowing only one writer to be active at any given time.

10. The memory 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 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 of claim 1, wherein the resource comprises data stored in computer memory.

13. The memory of claim 1, wherein the resource comprises a computer file.

14. The memory of claim 1, wherein the resource comprises an input/output device.

15. The memory 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.

16. The memory 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 may be 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.

17. The memory of claim 16, wherein the clearing ensures that one and only one posting to a writer of an event occurs.

18. The memory of claim 17, wherein the posting occurs if status of the writer active data is not set.

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

executing instructions on a computer system for receiving a request from an executable entity to access a resource within the computer system; and

executing instructions on the computer system for determining how to process the resource request based upon lock state data that is stored in a computer-readable storage medium;

wherein the 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 the reader data is indicative of whether a reader executable entity is active and attempting to read from the resource;

wherein the write requested data has a set status when a write request has been made, wherein the set status indicates whether a mutex lock is to be used for processing access to the resource, wherein the set status is set to indicate that the mutex lock is not to be used if no write request is pending;

executing instructions on the computer system for accessing the resource based upon said determining of how to process the resource request based upon lock state data.