TRANSACTIONAL LOCK ELISION WITH DELAYED LOCK CHECKING

• US 20140298342A1
• Filed: 03/27/2014
• Published: 10/02/2014
• Est. Priority Date: 03/26/2013
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Michael, Maged M., Mitran, Marcel, Ohmacht, Martin, Wang, Kai-Ting Amy
• Granted Patent: US 9,529,838 B2
• Time in Patent Office: Days
• US Class Current: 718/101
• CPC Class Codes: G06F 12/1475 in a virtual system, e.g. with translation means
• CPC Class Codes: G06F 16/2343 Locking methods, e.g. distributed locking or locking implementation details
• CPC Class Codes: G06F 2212/1052 Security improvement
• CPC Class Codes: G06F 3/0619 in relation to data integrity, e.g. data losses, bit errors
• CPC Class Codes: G06F 3/0637 Permissions
• CPC Class Codes: G06F 3/0644 Management of space entities, e.g. partitions, extents, pools
• CPC Class Codes: G06F 3/067 Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: G06F 9/467 Transactional memory G06F9/528 takes precedence
• CPC Class Codes: G06F 9/524 Deadlock detection or avoidance

Abstract

Avoiding data conflicts includes initiating a transactional lock elision transaction containing a critical section, executing the transactional lock elision transaction including the critical section, and checking a status of a lock prior to a commit point in the transactional lock elision transaction executing, wherein the checking the status occurs after processing the critical section. A determination of whether the status of the lock checked is free is made and, responsive to a determination the lock checked is free, a result of the transactional lock elision transaction is committed.

Claims

1. A method for transactional lock elision, the method comprising:

initiating a transactional lock elision transaction containing a critical section;

executing the transactional lock elision transaction including the critical section using a processor;

checking a status of a lock prior to a commit point in the transactional lock elision transaction executing, wherein the checking the status occurs after processing the critical section;

determining whether the status of the lock checked is free; and

responsive to a determination the lock checked is free, committing a result of the transactional lock elision transaction.

2. The method of claim 1 wherein responsive to a determination the lock checked is not free, selecting an action from a set of alternate actions.

3. The method of claim 2, wherein the set of alternate actions comprises actions including performing a short spin loop and performing a wait-notify.

4. The method of claim 2, further comprising:

performing at least one alternate action selected from the set of alternate actions.

5. The method of claim 1, further comprising:

calculating a cost associated with checking the lock;

analyzing the cost using an expression of Probability(lock_read_early/late_by_THREAD1 collides_with lock_held_by_THREAD2)*(overhead_failing_TLE_transaction+wasted_work_done_inside_TLE_transaction); and

identifying one of a lock read early or a lock read late using a result of the cost analyzing.

6. The method of claim 5, further comprising:

storing results of the identifying one of a lock read early or a lock read late using a result of the cost analyzing into a database; and

using the results stored to guide and adapt subsequent runs of a same or similar transaction.

7. The method of claim 1, wherein a time window from reading the lock early to a commit time as in conventional implementation of lock elision is greater than a time window from reading the lock late to the commit time as in deferred locking, wherein a probability of conflict on the lock in deferred locking is less than the probability of conflict on the lock in conventional locking

8-20. -20. (canceled)