Method and system for enhanced thread synchronization and coordination

• US 20070271450A1
• Filed: 05/17/2006
• Published: 11/22/2007
• Est. Priority Date: 05/17/2006
• Status: Abandoned Application

• Current Assignee: Intel Corporation
• Original Assignee: Intel Corporation
• Inventors: Wang, Hong, Jacobson, Quinn A., Doshi, Kshitij A., Bracy, Anne W.
• Application Number:
  US11/436,292
• Publication Number:
  US 20070271450A1
• Time in Patent Office: Days
• US Class Current: 712/245
• CPC Class Codes: G06F 12/0815 Cache consistency protocols
• CPC Class Codes: G06F 2209/523 Mode
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms

Abstract

Synchronization and communication between concurrent software threads is enhanced. An attempt may be made to acquire a lock associated with a resource. If the lock is not available and/or the attempt fails, a hardware monitor may be configured to detect release of the lock. An asynchronous procedure call responsive to detection of the lock release facilitates another attempt to acquire the lock. Alternatively, upon acquiring the lock a hardware monitor may be configured to detect any attempt to acquire the lock. Access to the protected resource may be maintained until an asynchronous procedure call responsive to the detection of such an attempt. Then state may be restored to a safe point for releasing the lock. Alternatively, processing of reader lock requests may be adapted to a turnstile processing when no writer holds or waits for the lock and then adapted to read-write lock processing whenever a writer requests the lock.

Claims

1. A machine implemented method comprising:

checking to determine if a lock associated with a protected resource is available;

if the lock is determined to be available, attempting to acquire the lock;

if the lock is not available or the attempt to acquire the lock fails, then;

configuring a hardware monitor to detect a release of the lock,

configuring an asynchronous call to a procedure, and

asynchronously entering the procedure responsive to detection of the lock release.

2. An article of manufacture comprising

a machine-accessible medium including data that, when accessed by a machine, causes the machine to perform the method of claim 1.

3. The method of claim 1 further comprising:

attempting to acquire the lock; and

if the attempt to acquire the lock succeeds, accessing the protected resource then releasing the lock.

4. The method of claim 1 wherein the hardware monitor is configured to detect the release of the lock at least in part by setting an attribute bit associated with the address of the lock.

5. The method of claim 4 wherein the hardware monitor is configured to detect the release of the lock at least in part by setting a scenario type associated with the set attribute bit.

6. A machine implemented method comprising:

attempting to acquire a lock associated with a protected resource;

if the attempt to acquire the lock succeeds, then;

configuring a hardware monitor to detect an attempt to acquire the lock,

configuring an asynchronous call to a procedure; and

accessing the protected resource,

asynchronously entering the procedure responsive to detection of the attempt to acquire the lock.

7. An article of manufacture comprising

a machine-accessible medium including data that, when accessed by a machine, causes the machine to perform the method of claim 6.

8. The method of claim 6 further comprising:

restoring state to a safe point for releasing the lock;

disabling the asynchronous procedure call; and

releasing the lock.

9. The method of claim 6 wherein the hardware monitor is configured to detect the attempt to acquire the lock at least in part by setting an attribute bit associated with the address of the lock.

10. The method of claim 9 wherein the hardware monitor is configured to detect the attempt to acquire the lock at least in part by setting a scenario type associated with the set attribute bit.

11. A machine implemented method comprising:

when no writer thread holds a write-lock and no writer thread waits for a read-lock release, then adapt to turnstile processing reader lock requests and reader unlock requests; and

when a writer thread holds the write-lock or a writer thread waits for the read-lock release, process any reader unlock requests until no reader thread holds the read-lock, then adapt to read-write processing writer lock and unlock request.

12. The apparatus of claim 11 wherein the write-lock indicates that a writer thread is presently contesting for access to a protected resource.

13. The apparatus of claim 12 wherein the write-lock is a mutually exclusive gate variable.

14. The apparatus of claim 11 wherein the read-lock indicates that a reader thread has access to a protected resource.

15. The apparatus of claim 12 wherein the read-lock is not a mutually exclusive variable.

16. An article of manufacture comprising

a machine-accessible medium including data that, when accessed by a machine, causes the machine to perform the method of claim 11.

17. A multithreaded computing system comprising:

an coherent addressable memory;

a processor comprising a configurable event monitor coupled with said coherent addressable memory to cause a procedure call in response to a memory event;

a program stored in said coherent addressable memory and executable by said processor, said program comprising a synchronized portion protected by a memory variable, a first execution thread having a synchronization procedure and a second execution thread, said first execution thread to enable said configurable event monitor to detect that the memory variable was accessed by said second execution thread and to cause an asynchronous call to said synchronization procedure in response.

18. The computing system of claim 17, wherein said memory variable is a lock variable to protect said synchronized portion.

19. The computing system of claim 18, said first execution thread further to:

check to determine if said lock variable is available;

if the lock variable is determined to be available, attempt to acquire the lock variable;

if the lock variable is not available or the attempt to acquire the lock variable fails, then enable said event monitor by configuring it to detect a release of the lock variable and to cause an asynchronous call to said synchronization procedure in response.

20. The computing system of claim 19, said first execution thread further to:

asynchronously enter the synchronization procedure responsive to detection of the lock variable'"'"'s release then attempt to acquire the lock variable; and

if the attempt to acquire the lock variable succeeds, access said synchronized portion of the program.

21. The computing system of claim 18, said first execution thread further to:

attempt to acquire the lock variable;

if the attempt to acquire the lock variable succeeds, then;

enable said event monitor by configuring it to detect an attempt to acquire the lock variable and to cause an asynchronous call to said synchronization procedure in response, and

access said synchronized portion of the program.

22. The computing system of claim 21, said first execution thread further to:

asynchronously enter the procedure responsive to detection of the attempt to acquire the lock variable then;

restoring state of said synchronized portion of the program to a safe point for releasing the lock,

disabling the asynchronous procedure call in said event monitor; and

releasing the lock.

23. The computing system of claim 17, said first execution thread further to:

check to determine if a write variable is set;

if the write variable is not set, set a read variable and increment a count variable;

otherwise if the write variable is set, then check to determine if the memory variable is set, and then if the memory variable is set, enable said event monitor to detect a changing of the memory variable and to cause an asynchronous call to said synchronization procedure in response.

24. The computing system of claim 23, said first execution thread further to:

asynchronously enter the synchronization procedure responsive to detection of the changing of the memory variable then if the memory variable is not set;

set the memory variable,

set the read variable,

increment the count variable, and

reset the memory variable.

25. The computing system of claim 23, said first execution thread further to:

decrement the count variable; and

if the decremented count variable has a value of zero, then reset the read variable.

26. The computing system of claim 18, said first execution thread further to:

check to determine if the lock variable is set;

if the lock variable is not set, then;

set the lock variable,

set a write variable,

check to determine if a read variable is set, then

if the read variable is not set, decrement the count variable, or

otherwise if the read variable is set, enable said event monitor to detect a changing of the read variable and to cause an asynchronous call to a wait synchronization procedure in response;

else

if the lock variable is set, then enable said event monitor to detect a changing of the lock variable and to cause an asynchronous call to said synchronization procedure in response.

27. The computing system of claim 26, said first execution thread further to:

increment the count variable;

reset the write variable; and

reset the lock variable.

28. The computing system of claim 17, said first execution thread further to:

enable said configurable event monitor to detect an unexpected coherency state for a memory address of the memory variable, the program further comprising a useful work module stored in the memory and activated by the configurable event monitor in response to the unexpected coherency state, said useful work module to perform useful work in the shadow of resolving said unexpected coherency state.