IP Library › Granted Patent US 12,346,753
Granted Patent B2
US 12,346,753 · App. 18/478,820 · Granted Jul 1, 2025

Systems and methods for safely subscribing to locks using hardware extensions

Inventors: David Dice (Foxboro, MA); Timothy L. Harris (Cambridge, GB); Alex Kogan (Needham, MA); Yosef Lev (New York, NY); Mark S. Moir (Wellington, NZ)
Assignee: Oracle International Corporation
G06F9/526G06F9/30087G06F9/3851G06F9/467
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,346,753
App. No.
18/478,820
Granted
Jul 1, 2025
Kind
B2
Abstract

Transactional Lock Elision allows hardware transactions to execute unmodified critical sections protected by the same lock concurrently, by subscribing to the lock and verifying that it is available before committing the transaction. A “lazy subscription” optimization, which delays lock subscription, can potentially cause behavior that cannot occur when the critical sections are executed under the lock. Hardware extensions may provide mechanisms to ensure that lazy subscriptions are safe (e.g., that they result in correct behavior). Prior to executing a critical section transactionally, its lock and subscription code may be identified (e.g., by writing their locations to special registers). Prior to committing the transaction, the thread executing the critical section may verify that the correct lock was correctly subscribed to. If not, or if locations identified by the special registers have been modified, the transaction may be aborted. Nested critical sections associated with different lock types may invoke different subscription code.

Claims (54)

1. A system, comprising:

one or more processor cores; and

a memory coupled to the one or more processor cores and storing program instructions that when executed on the one or more processor cores cause the one or more processor cores to execute a multithreaded application that comprises a critical section, wherein the critical section is associated with a lock, and wherein a thread of the multithreaded application is configured to:

store information identifying the lock in a lock address register; and

execute the critical section using a hardware transaction, wherein to execute the critical section the thread is configured to:

subscribe, within the hardware transaction, to a boolean register associated with the lock, wherein to subscribe to the boolean register the thread is configured to:

determine, according to the boolean register, whether another critical section associated with the lock is currently being executed; and

in response to determining that said other critical section associated with the lock is not currently being executed and the lock address register has not been modified during execution of the hardware transaction, commit the hardware transaction.

2. The system of claim 1 , wherein the thread of the multithreaded application is further configured to abort the hardware transaction in response to determining that another critical section associated with the lock is currently being executed or the lock address register has been modified during execution of the hardware transaction.

3. The system of claim 1 , wherein the information identifying the lock comprises a location of the boolean register residing in a hardware transactional memory.

4. The system of claim 3 , wherein subscribing to the boolean register is performed in response to encountering, during execution of the critical section using the hardware transaction, an instruction that signals an end of the critical section, and wherein to subscribe to the boolean register the thread is further configured to:

read a value from the location identified by the information; and

determine, dependent on the value read from the location, whether another critical section associated with the lock is currently being executed.

5. The system of claim 1 , wherein the thread of the multithreaded application is further configured to:

enter, immediately prior to subscribing to the boolean register, a special mode in which attempts to execute code in the write set of the hardware transaction and attempts to read data in the write set of the hardware transaction are disallowed; and

abort the hardware transaction in response to an attempt by the thread to execute code that is in the write set of the hardware transaction while in the special mode, in response to an attempt by the thread to read data that is in the write set of the hardware transaction while in the special mode, or in response to another thread acquiring the lock.

6. A computer implemented method, comprising:

performing, by a thread of a multi-threaded application executing on a computer that supports multithreading:

storing information identifying a lock in a lock address register; and

executing a critical section using a hardware transaction, comprising:

subscribing, within the hardware transaction, to a boolean register associated with the lock, comprising:

determining, according to the boolean register, whether another critical section protected by the lock is currently being executed; and

in response to determining that said other critical section protected by the lock is not currently being executed and the lock address register has not been modified during execution of the hardware transaction, committing the hardware transaction.

7. The system of claim 1 , wherein a protected memory area of a given size comprises:

the lock address register storing a value identifying a location at which the lock associated with the critical section resides in a hardware transactional memory; and

wherein the one or more processor cores are configured to abort the hardware transaction in response to an attempt, during execution of the hardware transaction, to reduce the size of the protected memory area.

8. The system of claim 6 , wherein the multithreaded application comprises two or more critical sections including the critical section and the other critical section.

9. The computer implemented method of claim 6 , the thread further performing aborting the hardware transaction in response to determining that another critical section protected by the lock is currently being executed or the lock address register has been modified during execution of the hardware transaction.

10. The computer implemented method of claim 6 , wherein the information identifying the lock comprises a location of the boolean register residing in a hardware transactional memory.

11. The computer implemented method of claim 10 , wherein subscribing to the boolean register is performed in response to encountering, during execution of the critical section using the hardware transaction, an instruction that signals an end of the critical section, and wherein subscribing to the boolean register comprises:

reading a value from the location identified by the information; and

determining, dependent on the value read from the location, whether another critical section protected by the lock is currently being executed.

12. The computer implemented method of claim 6 , the thread further performing:

entering, immediately prior to subscribing to the boolean register, a special mode in which attempts to execute code in the write set of the hardware transaction and attempts to read data in the write set of the hardware transaction are disallowed; and

aborting the hardware transaction in response to an attempt by the thread to execute code that is in the write set of the hardware transaction while in the special mode, in response to an attempt by the thread to read data that is in the write set of the hardware transaction while in the special mode, or in response to another thread acquiring the lock.

13. The computer implemented method of claim 6 , wherein the multithreaded application comprises two or more critical sections including the critical section and the other critical section.

14. The computer implemented method of claim 6 , wherein a protected memory area of a given size comprises:

the lock address register storing a value identifying a location at which the lock associated with the critical section resides in a hardware transactional memory; and

wherein the one or more processor cores are configured to abort the hardware transaction in response to an attempt, during execution of the hardware transaction, to reduce the size of the protected memory area.

15. One or more non-transitory computer-readable storage media storing program instructions that when executed on or across one or more computers cause the one or more computers to implement a thread of a multi-threaded application to perform:

storing information identifying a lock in a lock address register; and

executing a critical section using a hardware transaction, comprising:

subscribing, within the hardware transaction, to a boolean register associated with the lock, comprising:

determining, according to the boolean register, whether another critical section protected by the lock is currently being executed; and

in response to determining that said other critical section protected by the lock is not currently being executed and the lock address register has not been modified during execution of the hardware transaction, committing the hardware transaction.

16. The one or more non-transitory, computer-readable storage media of claim 15 , the thread further performing aborting the hardware transaction in response to determining that another critical section protected by the lock is currently being executed or the lock address register has been modified during execution of the hardware transaction.

17. The one or more non-transitory, computer-readable storage media of claim 15 , wherein the information identifying the lock comprises a location of the boolean register residing in a hardware transactional memory.

18. The one or more non-transitory, computer-readable storage media of claim 17 , wherein subscribing to the boolean register is performed in response to encountering, during execution of the critical section using the hardware transaction, an instruction that signals an end of the critical section, and wherein subscribing to the boolean register comprises:

reading a value from the location identified by the information; and

determining, dependent on the value read from the location, whether another critical section protected by the lock is currently being executed.

19. The one or more non-transitory, computer-readable storage media of claim 15 , the thread further performing:

entering, immediately prior to subscribing to the boolean register, a special mode in which attempts to execute code in the write set of the hardware transaction and attempts to read data in the write set of the hardware transaction are disallowed; and

aborting the hardware transaction in response to an attempt by the thread to execute code that is in the write set of the hardware transaction while in the special mode, in response to an attempt by the thread to read data that is in the write set of the hardware transaction while in the special mode, or in response to another thread acquiring the lock.

20. The one or more non-transitory, computer-readable storage media of claim 15 , wherein the multithreaded application comprises two or more critical sections including the critical section and the other critical section.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Oct 3, 2023
From: DICE, DAVID; HARRIS, TIMOTHY L.; KOGAN, ALEX; LEV, YOSEF; MOIR, MARK S.
To: ORACLE INTERNATIONAL CORPORATION
Reel/Frame 065110/0230 →
Continuity (4)
Continuation 16723766 · Dec 20, 2019
Continuation 14736123 · Jun 10, 2015
Provisional Application 62024415 · Jul 14, 2014
Related Publication 20240028424A1 · Jan 25, 2024
References Cited (27)
US 8495607B2 · Gschwind · 2013 [cited by applicant]
US 10521277B2 · Dice et al. · 2019 [cited by applicant]
US 20030037223A1 · Steely, Jr. et al. · 2003 [cited by applicant]
US 20050268106A1 · Mansell et al. · 2005 [cited by applicant]
US 20060031844A1 · Dice et al. · 2006 [cited by applicant]
US 20070186056A1 · Saha et al. · 2007 [cited by applicant]
US 20090007070A1 · Magruder et al. · 2009 [cited by applicant]
US 20110246725A1 · Moir et al. · 2011 [cited by applicant]
US 20120227045A1 · Knauth et al. · 2012 [cited by applicant]
US 20120254846A1 · Moir et al. · 2012 [cited by applicant]
US 20140040567A1 · Pohlack et al. · 2014 [cited by applicant]
US 20150074366A1 · Calciu et al. · 2015 [cited by applicant]
US 20150277967A1 · Calciu et al. · 2015 [cited by applicant]
US 20150378912A1 · Gschwind et al. · 2015 [cited by applicant]
US 20150378927A1 · Bradbury et al. · 2015 [cited by applicant]
US 20210191788A1 · Dice et al. · 2021 [cited by applicant]
Ole Agesen, et al., “An Efficient Meta-lock for Implementing Ubiquitous Synchronization”, Sun Microsystems, Apr. 1999, pp. 1-27. [cited by applicant]
David F. Bacon, et al., “Thin Locks: Featherweight Synchronization for Java”, Proceedings of the ACM Conference on Programming Language Design and Implementation, SIGPLAN, Jun. 1998, pp. 1-11, vol. 33, No. 6, Montreal, … [cited by applicant]
Travis S. Craig, “Building FIFO and Priority-Queuing Spin Locks from Atomic Swap”, Department of Computer Science and Engineering, University of Washington, Feb. 1, 1993, pp. 1-29, Seattle, Washington. [cited by applicant]
Luke Dalessandro, et al., “Hybrid NOrec: A Case Study in the Effectiveness of Best Effort Hardware Transactional Memory”, ACM, ASPLOS'11, ACM, Mar. 5-11, 2011, pp. 1-13. [cited by applicant]
David Dice, “Brief Announcement: A Partitioned Ticket Lock”, ACM, SPAA'11, Jun. 4-6, 2011, pp. 309-310, San Jose, California, USA. [cited by applicant]
David Dice, et al., “Applications of the Adaptive Transactional Memory Test Platform”, Sun Microsystems, Inc., 2008, pp. 1-10. [cited by applicant]
Peter Magnusson, et al., “Queue Locks on Cache Coherent Multiprocessors”, IEEE, 8th International Parallel Processing Symposium, Apr. 26-29, 1994, pp. 1-7. [cited by applicant]
Alexander Matveev, et al., “Reduced Hardware Transactions: A New Approach to Hybrid Transactional Memory”, ACM, Transact '13, Mar. 17, 2013, pp. 1-11, Houston, Texas USA. [cited by applicant]
John M. Mellor-Crummey, et al., “Algorithms for Scalable Synchronization on Share-Memory Multiprocessors”, ACM Trans. on Computer Systems, Jan. 1991, pp. 1-41. [cited by applicant]
Ravi Rajwar, et al., “Speculative Lock Elision: Enabling Highly Concurrent Multithreaded Excecution”, Proceedings of the 34th International Symposium of Microarchitecture (MICRO), Dec. 3-5, 2001, pp. 1-12, Austin, Texas. [cited by applicant]
Dave Dice, et al., “Adaptived Integration of Hardware and Software Lock Elision Techniques”, ACM, SPAA'14, Jun. 23-25, 2014, pp. 1-10, Prague, Czech Republic. [cited by applicant]