Resource accessing with locking

• US 7,603,502 B2
• Filed: 04/12/2005
• Issued: 10/13/2009
• Est. Priority Date: 04/12/2005
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Clark, Jason D., Richter, Jeffrey M.
• Primary Examiner(s): Lee; Thomas
• Assistant Examiner(s): Rehman; Mohammed H
• Application Number:
  US11/103,854
• Publication Number:
  US 20060230411A1
• Time in Patent Office: 1,645 Days
• Field of Search: 710/260, 710/112, 710/240, 710/6, 710/200, 711/152, 718/104
• US Class Current: 710/200
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms

Abstract

Thread usage is managed when locking resources during the possibly-contentious accessing of such resources. In a described implementation, a thread that is executing a corresponding access request is not suspended when its corresponding access request is delayed because a targeted resource is currently locked for accessing by another thread. Instead, when a targeted resource is locked, the blocked access request is queued up in a queue of access requests. The corresponding thread is then permitted to perform other work. When the resource is subsequently unlocked and thus becomes available, an access request (e.g., the oldest or highest priority access request) that is queued is retrieved, and a thread is allowed to execute it. Implementations for general locking access schemes, for read/write-bifurcated locking access schemes, etc. are described. Implementations are described from conceptual, functional, temporal, code or function, contention, thread, and other perspectives.

Claims

1. A system for thread handling, the system comprising:

at least one processor;

a target resource;

a first thread to handle a first access request to at least the target resource; and

a resource locking mechanism to release the first thread during the handling of the first access request for the target resource when the resource locking mechanism determines that the target resource is already locked for access by a write access request, so that the released first thread is capable of handling at least a second access request,

and to permit the first access request handled by the first thread to access the target resource when the resource locking mechanism determines that the first access request is a first read access request and the target resource is already locked for access by a second read access request a second thread to handle a second access request to at least the target resource, wherein the resource locking mechanism is to permit the second access request handled by the second thread to access the target resource when the resource locking mechanism determines that the second access request is third read access request and the target resource is already locked for access by the second read access request.

2. The system as recited in claim 1, wherein the resource locking mechanism is further configured to queue the first access request when the target resource is already locked for access by the write access request.

3. The system as recited in claim 2, wherein the resource locking mechanism is further configured (i) to retrieve the queued first access request when the target resource is no longer locked for access by the write access request and (ii) to fulfill the retrieved first access request.

4. The system as recited in claim 3, wherein the resource locking mechanism is further configured (i) to retrieve multiple queued read access requests when the targeted resource is no longer locked and (ii) to assign a determinable number of threads to a subset of read access requests of the retrieved multiple read access requests, the determinable number equal to a number of available processors of the system.

5. The system as recited in claim 2, wherein the resource locking mechanism is further configured to queue the first access request on at least one access request queue by adding an access request identifier to the at least one access request queue.

6. The system as recited in claim 1, wherein the target resource comprises at least one of a file, a database, an object, a class, a document, a printer, a network connection, a video processor, or a video display screen.

7. One or more processor-accessible storage media comprising processor-executable instructions that include at least one application programming interface (API), the at least one API to handle access requests for a resource;

the at least one API to

queue a first access request and to release a first thread executing the first access request without suspending the first thread when the resource is already write locked, and to permit the first access request to be performed on the resource when the first access request is a read access request and the resource is already read locked, and

permit a second access request that is executed by a second thread to access the resource when the second access request is a second read access request and the resource is already read locked.

8. The one or more processor-accessible storage media as recited in claim 7, wherein the at least one API is to further queue access requests that are write access requests when the resource is already write locked.

9. The one or more processor-accessible storage media as recited in claim 7, wherein the at least one API is to further queue access requests that are read access requests when a write is occurring to the resource.

10. The one or more processor-accessible storage media as recited in claim 9, wherein the at least one API is to further permit new access requests that are read access requests to be concurrently performed with previous read access requests when no write access request is pending for the resource.

11. The one or more processor-accessible storage media as recited in claim 7, wherein the at least one API is to further retrieve the queued first access request and to permit performance of the retrieved first access request when the resource is no longer write locked.

12. The one or more processor-accessible storage media as recited in claim 11, wherein the at least one API is to further retrieve multiple queued read access requests when contention caused by one or more write accesses is terminated;

and wherein the at least one API is to further assign a determinable number of threads to a subset of read access requests of the retrieved multiple read access requests, the determinable number equal to a number of available processors.

13. The one or more processor-accessible storage media as recited in claim 7, wherein the at least one API comprises at least two APIs;

and wherein the at least two APIs comprise a read locking API that handles read access requests and a write locking API that handles write access requests.

14. The one or more processor-accessible storage media as recited in claim 13, wherein the read locking API is further (i) to queue read access requests in a read access request queue when the resource is already locked for a write access request and (ii) to permit concurrent read access requests;

and wherein the write locking API is to queue write access requests in a write access request queue when the resource is already locked for a write access request or one or more read access requests.

15. A method implemented by a device, the method comprising:

starting, by a first thread, performance of a first access request that is targeting a resource;

detecting, by the first thread, that the resource is already locked for a read access or a write access by a second thread;

performing, by the first thread, the first access request when the resource is already locked for the read access by the second thread and the first access request is a read access request;

queuing, by the first thread, the first access request when the resource is already locked for the write access by the second thread;

completing, by a third thread, performance of the first access request when the resource is no longer locked for write access by the second thread, and

performing, by a fourth thread, a second access request that is targeting the resource when the resource is already locked for the read access by the second thread and the second access request is another read access request.

16. The device-implemented method as recited in claim 15, wherein the queuing comprises queuing the first access request by adding an access request identifier associated with the access request to at least one access request queue;

wherein the access request identifier comprises at least one of a code, a pointer, an address, a function name, or a function location.

17. The device-implemented method as recited in claim 15, wherein the completing comprises:

retrieving the queued first access request from at least one access request queue; and

performing the first access request by accessing the resource in accordance with the first access request.

18. The device-implemented method as recited in claim 17, further comprising:

retrieving multiple read access requests from the at least one access request queue; and

assigning a determinable number of threads to a subset of read access requests of the retrieved multiple read access requests, the determinable number equal to a number of available processors.

19. The device-implemented method as recited in claim 15, wherein the first thread differs from the third thread at least to an extent such that an identifiable thread performs other work between when it executes at least one function as the first thread and when it executes at least one function as the third thread.