Systems and methods for adaptive integration of hardware and software lock elision techniques
Particular techniques for improving the scalability of concurrent programs (e.g., lock-based applications) may be effective in some environments and for some workloads, but not others. The systems described herein may automatically choose appropriate ones of these techniques to apply when executing lock-based applications at runtime, based on observations of the application in the current environment and with the current workload. In one example, two techniques for improving lock scalability (e.g., transactional lock elision using hardware transactional memory, and optimistic software techniques) may be integrated together. A lightweight runtime library built for this purpose may adapt its approach to managing concurrency by dynamically selecting one or more of these techniques (at different times) during execution of a given application. In this Adaptive Lock Elision approach, the techniques may be selected (based on pluggable policies) at runtime to achieve good performance on different platforms and for different workloads.
1. A method, comprising:
performing by a computer:
beginning instrumentation of code of a multithreaded application,
wherein the application comprises at least one critical section of code that is associated with a lock, and wherein when the lock is held by a thread, other threads are prevented from accessing resources that are protected by the lock;
declaring, for one or more respective locks of the at least one critical section, metadata for use by an adaptive lock elision library, wherein the metadata for a given lock comprises a respective label corresponding to the given lock;
selecting one of a plurality of mechanisms for executing the critical section without acquiring the lock; and
instrumenting the critical section for execution using the selected one of the plurality of mechanisms, wherein the instrumenting the critical section comprises replacing a call for the lock with a call to the adaptive lock elision library.
2. The method of claim 1 , wherein said selecting one of the plurality of mechanisms comprises:
determining whether to attempt to execute the critical section using hardware transactional memory or to execute the critical section using an optimistic alternative code path.
3. The method of claim 2 , wherein the adaptive lock elision library is configured to determine whether the execution using the hardware transactional memory may result in a potential conflict with one or more concurrently executing optimistic alternative code paths.
4. The method of claim 1 , further comprising:
providing an application programming interface (API) configured to allow a user to select whether to attempt to execute a critical section of code using a hardware transactional memory or to execute the critical section using an optimistic alternative code path.
5. The method of claim 1 , further comprising:
instrumenting the code to identify a conflict region within the critical section, wherein the conflict region comprises program instructions that, when executed, are capable of causing a conflict with another thread that is executing a respective critical section of code in the application that is associated with the lock.
6. The method of claim 1 , further comprising:
instrumenting the code of the multithreaded application to specify one or more values of parameters to pass to an optimistic alternative code path or to the adaptive lock elision library.
7. The method of claim 1 , further comprising:
creating a lock Application Programming Interface (API) instance for the lock, wherein the lock API instance is configured to define a lock function, an unlock function, and an is-locked function corresponding to a respective lock type of the lock.
8. 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:
begin instrumentation of code of a multithreaded application,
wherein the application comprises at least one critical section of code that is associated with a lock, and wherein when the lock is held by a thread, other threads are prevented from accessing resources that are protected by the lock;
declare, for one or more respective locks of the at least one critical section, metadata for use by an adaptive lock elision library, wherein the metadata for a given lock comprises a respective label corresponding to the given lock;
select one of a plurality of mechanisms for executing the critical section without acquiring the lock; and
instrumenting the critical section for execution using the selected one of the plurality of mechanisms, wherein the instrumenting the critical section comprises replacing a call for the lock with a call to the adaptive lock elision library.
9. The system of claim 8 , wherein to select one of the plurality of mechanisms the one or more processor cores are configured to:
determine whether to attempt to execute the critical section using hardware transactional memory or to execute the critical section using an optimistic alternative code path.
10. The system of claim 8 , wherein the memory further comprises program instructions that when executed on the one or more processor cores cause the one or more processor cores to: provide an application programming interface (API) configured to allow a user to select whether to attempt to execute a critical section of code using a hardware transactional memory or to execute the critical section using an optimistic alternative code path.
11. The system of claim 8 , wherein the memory further comprises program instructions that when executed on the one or more processor cores cause the one or more processor cores to:
instrument the code to identify a conflict region within the critical section, wherein the conflict region comprises program instructions that, when executed, are capable of causing a conflict with another thread that is executing a respective critical section of code in the application that is associated with the lock.
12. The system of claim 8 , wherein the memory further comprises program instructions that when executed on the one or more processor cores cause the one or more processor cores to:
instrument the code of the multithreaded application to specify one or more values of parameters to pass to an optimistic alternative code path or to the adaptive lock elision library.
13. The system of claim 8 , wherein the memory further comprises program instructions that when executed on the one or more processor cores cause the one or more processor cores to:
create a lock API instance for the lock, wherein the lock API instance is configured to define a lock function, an unlock function, and an is-locked function corresponding to a respective lock type of the lock.
14. The system of claim 8 , wherein the adaptive lock elision library is configured to determine whether the execution using the hardware transactional memory may result in a potential conflict with one or more concurrently executing optimistic alternative code paths.
15. A non-transitory, computer-readable storage medium storing program instructions that when executed on one or more computers cause the one or more computers to perform:
beginning instrumentation of a multithreaded application,
wherein the application comprises at least one critical section of code that is associated with a lock, and wherein when the lock is held by a thread, other threads are prevented from accessing resources that are protected by the lock;
declaring, for one or more respective locks of the at least one critical section, metadata for use by an adaptive lock elision library, wherein the metadata for a given lock comprises a respective label corresponding to the given lock;
selecting one of a plurality of mechanisms for executing the critical section without acquiring the lock; and
instrumenting the critical section for execution using the selected one of the plurality of mechanisms, wherein the instrumenting the critical section comprises replacing a call for the lock with a call to the adaptive lock elision library.
16. The non-transitory, computer-readable storage medium of claim 15 , wherein said selecting one of the plurality of mechanisms comprises:
determining whether to attempt to execute the critical section using hardware transactional memory or to execute the critical section using an optimistic alternative code path.
17. The non-transitory, computer-readable storage medium of claim 15 , further comprising:
providing an application programming interface (API) configured to allow a user to select whether to attempt to execute a critical section of code using the hardware transactional memory or to execute the critical section using an optimistic alternative code path.
18. The non-transitory, computer-readable storage medium of claim 15 , further comprising:
instrumenting the code to identify a conflict region within the critical section, wherein the conflict region comprises program instructions that, when executed, are capable of causing a conflict with another thread that is executing a respective critical section of code in the application that is associated with the lock.
19. The non-transitory, computer-readable storage medium of claim 15 , further comprising:
instrumenting the code of the multithreaded application to specify one or more values of parameters to pass to an optimistic alternative code path or to the adaptive lock elision library.
20. The non-transitory, computer-readable storage medium of claim 15 , further comprising:
creating a lock API instance for the lock, wherein the lock API instance is configured to define a lock function, an unlock function, and an is-locked function corresponding to a respective lock type of the lock.