ADAPTIVE PROCESS FOR DATA SHARING WITH SELECTION OF LOCK ELISION AND LOCKING

• US 20150242246A1
• Filed: 02/27/2014
• Published: 08/27/2015
• Est. Priority Date: 02/27/2014
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Gschwind, Michael Karl, Michael, Maged M., Salapura, Valentina, Shum, Chung-Lung K.
• Granted Patent: US 9,524,195 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1407 Checkpointing the instruction stream
• CPC Class Codes: G06F 11/1441 Resetting or repowering
• CPC Class Codes: G06F 11/1474 in transactions G06F16/20 takes precedence
• CPC Class Codes: G06F 11/3024 where the computing system component is a central processing unit [CPU]
• CPC Class Codes: G06F 11/3419 by assessing time
• CPC Class Codes: G06F 9/30047 Prefetch instructions; cache control instructions
• CPC Class Codes: G06F 9/522 Barrier synchronisation
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms
• CPC Class Codes: G06F 9/528 by using speculative mechanisms
• CPC Class Codes: G06N 5/02 Knowledge representation; Symbolic representation

Abstract

In a Hardware Lock Elision (HLE) Environment, predictively determining whether a HLE transaction should actually acquire a lock and execute non-transactionally, is provided. Included is, based on encountering an HLE lock-acquire instruction, determining, based on an HLE predictor, whether to elide the lock and proceed as an HLE transaction or to acquire the lock and proceed as a non-transaction; based on the HLE predictor predicting to elide, setting the address of the lock as a read-set of the transaction, and suppressing any write by the lock-acquire instruction to the lock and proceeding in HLE transactional execution mode until an xrelease instruction is encountered wherein the xrelease instruction releases the lock or the HLE transaction encounters a transactional conflict; and based on the HLE predictor predicting not-to-elide, treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction, and proceeding in non-transactional mode.

Claims

1. A method, in a Hardware Lock Elision (HLE) Environment, for predictively determining whether a HLE transaction should actually acquire a lock and execute non-transactionally, the method comprising:

based on encountering a HLE lock-acquire instruction, determining, based on a HLE predictor, whether to elide the lock and proceed as an HLE transaction or to acquire the lock and proceed as a non-transaction;

based on the HLE predictor predicting to elide, setting an address of the lock as a read-set of the HLE transaction, and suppressing any write by the lock-acquire instruction to the lock and proceeding in HLE transactional execution mode until a xrelease instruction is encountered wherein the xrelease instruction releases the lock or the HLE transaction encounters a transactional conflict; and

based on the HLE predictor predicting not-to-elide, treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction, and proceeding in non-transactional mode.

2. The method according to claim 1, further comprising:

updating the HLE predictor based on a success of prediction of the HLE transactions, the HLE predictor predicting whether a HLE transaction is likely to abort.

3. The method according to claim 1, further comprising:

based on encountering a HLE transaction having the lock address for the first time, initializing a count of successful HLE transaction executions associated with the lock address to zero;

based on aborting any subsequent HLE transaction having the lock address, incrementing a count of failed HLE transaction executions associated with the lock address of the HLE transaction in the predictor;

based on completing any subsequent HLE transaction having the lock address, incrementing the count of successful HLE transaction executions associated with the lock address of the HLE transaction in the HLE predictor, wherein a high count of failed HLE transaction executions indicates likely to abort.

4. The method according to claim 1, further comprising:

monitoring, in non-transactional mode, attempted accesses to the lock by another process; and

incrementing the count of failed HLE transaction executions when the attempted access by the other process is detected.

5. The method according to claim 1, further comprising:

tracking the count of successful HLE transaction executions and the count of failed HLE transaction executions within a time window;

comparing the count of failed HLE transaction executions to a threshold number of failures during the time window; and

defaulting to non-transactional mode for the remainder of the time window, based upon the count of failed HLE transaction executions exceeding the threshold number of failures.

6. The method according to claim 5, further comprising:

resetting to zero the count of successful HLE transaction executions and the count of failed HLE transaction executions, based on the time window expiring.

7. A computer program product, in a Hardware Lock Elision (HLE) Environment, for predictively determining whether a HLE transaction should actually acquire a lock and execute non-transactionally, the computer program product comprising:

a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method comprising;

based on encountering an HLE lock-acquire instruction, determining, based on an HLE predictor, whether to elide the lock and proceed as an HLE transaction or to acquire the lock and proceed as a non-transaction;

based on the HLE predictor predicting to elide, setting the address of the lock as a read-set of the transaction, and suppressing any write by the lock-acquire instruction to the lock and proceeding in HLE transactional execution mode until an xrelease instruction is encountered wherein the xrelease instruction releases the lock or the HLE transaction encounters a transactional conflict; and

based on the HLE predictor predicting not-to-elide, treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction, and proceeding in non-transactional mode.

8. The computer program product according to claim 7, further comprising:

updating the HLE predictor based on success of prediction of HLE transactions, the HLE predictor predicting whether an HLE is likely to abort.

9. The computer program product according to claim 7, further comprising:

monitoring, in non-transactional mode, attempted accesses to the lock by another process; and

incrementing the count of failed HLE transaction executions when the attempted access by the other process is detected.

10. The computer program product according to claim 7, further comprising:

monitoring, in a non-transactional mode, attempted accesses by another process to a memory region protected by the lock; and

incrementing the count of failed HLE transaction executions when the attempted access by the other process is detected.

11. The computer program product according to claim 7, further comprising:

based on encountering an HLE transaction having the lock address for the first time, initializing a count associated with the lock address to zero;

based on aborting any subsequent HLE transaction having the lock address, incrementing a count associated with the lock address of the HLE transaction in the predictor;

based on completing any subsequent HLE transaction having the lock address, incrementing the count of successful HLE transaction executions associated with the lock address of the HLE transaction in the predictor, wherein a high count of failed HLE transaction executions indicates likely to abort.

12. The computer program product according to claim 7, further comprising:

tracking the count of successful HLE transaction executions and the count of failed HLE transaction executions within a time window;

comparing the count of failed HLE transaction executions to a threshold number of failures during the time window; and

defaulting to non-transactional mode for the remainder of the time window, based upon the count of failed HLE transaction executions exceeding the threshold number of failures.

13. The computer program product according to claim 12, further comprising:

resetting to zero the count of successful HLE transaction executions and the count of failed HLE transaction executions, based on the time window expiring.

14. A computer system, in a Hardware Lock Elision (HLE) Environment, for predictively determining whether a HLE transaction should actually acquire a lock and execute non-transactionally, the computer system comprising:

a memory; and

a processor in communications with the memory, wherein the computer system is configured to perform a method, the method comprising;

based on encountering an HLE lock-acquire instruction, determining, based on an HLE predictor, whether to elide the lock and proceed as an HLE transaction or to acquire the lock and proceed as a non-transaction;

based on the HLE predictor predicting to elide, setting the address of the lock as a read-set of the transaction, and suppressing any write by the lock-acquire instruction to the lock and proceeding in HLE transactional execution mode until an xrelease instruction is encountered wherein the xrelease instruction releases the lock or the HLE transaction encounters a transactional conflict; and

based on the HLE predictor predicting not-to-elide, treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction, and proceeding in non-transactional mode.

15. The computer system according to claim 14, further comprising:

updating the HLE predictor based on success of prediction of HLE transactions, the HLE predictor predicting whether an HLE is likely to abort.

16. The computer system according to claim 14, further comprising:

monitoring, in non-transactional mode, attempted accesses to the lock by another process; and

incrementing the count of failed HLE transaction executions when the attempted access by the other process is detected.

17. The computer system according to claim 14, further comprising:

monitoring, in a non-transactional mode, attempted accesses by another process to a memory region protected by the lock; and

incrementing the count of failed HLE transaction executions when the attempted access by the other process is detected.

18. The computer system according to claim 14, further comprising:

based on encountering an HLE transaction having the lock address for the first time, initializing a count associated with the lock address to zero;

based on aborting any subsequent HLE transaction having the lock address, incrementing a count associated with the lock address of the HLE transaction in the predictor;

based on completing any subsequent HLE transaction having the lock address, incrementing the count of successful HLE transaction executions associated with the lock address of the HLE transaction in the predictor, wherein a high count of failed HLE transaction executions indicates likely to abort.

19. The computer system according to claim 14, further comprising:

tracking the count of successful HLE transaction executions and the count of failed HLE transaction executions within a time window;

comparing the count of failed HLE transaction executions to a threshold number of failures during the time window; and

defaulting to non-transactional mode for the remainder of the time window, based upon the count of failed HLE transaction executions exceeding the threshold number of failures.

20. The computer system according to claim 19, further comprising:

resetting to zero the count of successful HLE transaction executions and the count of failed HLE transaction executions, based on the time window expiring.