By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), September 13, 2012 10:56 am
Room: Moderated Discussions
Paul A. Clayton (paaronclayton.delete@this.gmail.com) on September 10, 2012 2:17 pm wrote:
[snip]
> Could this then require separately compiled code that uses locks
> either use the same compiler and options (so that all
> critical/locked sections are in transactions) or limit use to HLE
It seems I was not thinking clearly. It seems that even when using RTM a lock address must be added to the read set--not only to guard against accidental use of locks instead of RTM but also to handle the use of locks in the case of conflict when using RTM. (Unfortunately, this seems to indicate that any failure involving a particular lock will tend to block non-conflicting transactions temporarily. Using retry with a conflict-avoiding delay could avoid having to set the lock under modest contention and when the lock is unset all waiting threads could try using transactions, so the penalty might be small.)
(It seems that in theory a transaction could check the lock at the beginning of the transaction, remove the lock address from the read set, and finally check the lock at the end of the transaction. Any locked sections that are fully enclosed within a transaction will be known to be non-conflicting. One could even conceive of setting up a short duration MWAIT-like operation to wait for the release of the lock so that the transaction could commit, but that seems excessively complex especially with the possibility of [partially] nested transactions.)
It looks like I would need to spend quite a bit more time thinking about this stuff before I even mostly understand it.
[snip]
> Could this then require separately compiled code that uses locks
> either use the same compiler and options (so that all
> critical/locked sections are in transactions) or limit use to HLE
It seems I was not thinking clearly. It seems that even when using RTM a lock address must be added to the read set--not only to guard against accidental use of locks instead of RTM but also to handle the use of locks in the case of conflict when using RTM. (Unfortunately, this seems to indicate that any failure involving a particular lock will tend to block non-conflicting transactions temporarily. Using retry with a conflict-avoiding delay could avoid having to set the lock under modest contention and when the lock is unset all waiting threads could try using transactions, so the penalty might be small.)
(It seems that in theory a transaction could check the lock at the beginning of the transaction, remove the lock address from the read set, and finally check the lock at the end of the transaction. Any locked sections that are fully enclosed within a transaction will be known to be non-conflicting. One could even conceive of setting up a short duration MWAIT-like operation to wait for the release of the lock so that the transaction could commit, but that seems excessively complex especially with the possibility of [partially] nested transactions.)
It looks like I would need to spend quite a bit more time thinking about this stuff before I even mostly understand it.
Topic | Posted By | Date |
---|---|---|
Article: Haswell TM Alternatives | David Kanter | 2012/08/21 09:17 PM |
Article: Haswell TM Alternatives | Håkan Winbom | 2012/08/21 11:52 PM |
Article: Haswell TM Alternatives | David Kanter | 2012/08/22 01:06 AM |
Article: Haswell TM Alternatives | anon | 2012/08/22 08:46 AM |
Article: Haswell TM Alternatives | Linus Torvalds | 2012/08/22 09:16 AM |
Article: Haswell TM Alternatives | Doug S | 2012/08/24 08:34 AM |
AMD's ASF even more limited | Paul A. Clayton | 2012/08/22 09:20 AM |
AMD's ASF even more limited | Linus Torvalds | 2012/08/22 09:41 AM |
Compiler use of ll/sc? | Paul A. Clayton | 2012/08/28 09:28 AM |
Compiler use of ll/sc? | Linus Torvalds | 2012/09/08 12:58 PM |
Lock recognition? | Paul A. Clayton | 2012/09/10 01:17 PM |
Sorry, I was confused | Paul A. Clayton | 2012/09/13 10:56 AM |
Filter to detect store conflicts | Paul A. Clayton | 2012/08/22 09:19 AM |
Article: Haswell TM Alternatives | bakaneko | 2012/08/22 02:02 PM |
Article: Haswell TM Alternatives | David Kanter | 2012/08/22 02:45 PM |
Article: Haswell TM Alternatives | bakaneko | 2012/08/22 09:56 PM |
Cache line granularity? | Paul A. Clayton | 2012/08/28 09:28 AM |
Cache line granularity? | David Kanter | 2012/08/31 08:13 AM |
A looser definition might have advantages | Paul A. Clayton | 2012/09/01 06:29 AM |
Cache line granularity? | rwessel | 2012/08/31 07:54 PM |
Alpha load locked granularity | Paul A. Clayton | 2012/09/01 06:29 AM |
Alpha load locked granularity | anon | 2012/09/02 05:23 PM |
Alpha pages groups | Paul A. Clayton | 2012/09/03 04:16 AM |
An alternative implementation | Maynard Handley | 2012/11/20 09:52 PM |
An alternative implementation | bakaneko | 2012/11/21 05:52 AM |
Guarding unread values? | Paul A. Clayton | 2012/11/21 08:39 AM |
Guarding unread values? | bakaneko | 2012/11/21 11:25 AM |
TM granularity and versioning | Paul A. Clayton | 2012/11/21 08:27 AM |
TM granularity and versioning | Maynard Handley | 2012/11/21 10:52 AM |
Indeed, TM (and coherence) has devilish details (NT) | Paul A. Clayton | 2012/11/21 10:56 AM |