topic Hi, in Intel® Moderncode for Parallel Architectures

Questions about TSX

Dmitry_Vyukov — Thu, 09 Feb 2012 09:10:19 GMT

Hi,

> 8.3.5RTM Abort Status Definition

Feedback and introspection seem to be critical for such systems; is it possible to get to know as to whether the abort was caused by a bad instruction (can't be executed in transactions at all, can't be executed in transactions on this particular processor) or by a memory protection fault (access to NULL), etc? It also would be useful to obtain PC and ADDR associated with abort.

> 8.3.6RTM Memory Ordering

>A successful RTM commit causes all memory operations in the RTM region to appear

>to execute atomically. A successfully committed RTM region consisting of an XBEGIN

>followed by an XEND, even with no memory operations in the RTM region, has the

>same ordering semantics as a LOCK prefixed instruction.

I am curious what is the rationale behind that. Does it mean that that adds several dozens of cycles to each trx? If I need MFENCE I can put it after a trx manually.

What are approximate sizes of read/write sets? Are we talking about like 4 cache lines? Or 128 cache lines? That critically affects what can be implemenmted with TSX.

TIA

Questions about TSX

SergeyKostrov — Fri, 10 Feb 2012 03:03:19 GMT

Quoting Dmitriy Vyukov

Hi,
> 8.3.5RTM Abort Status Definition
...is it possible to get to know as to whether the abort was caused by a bad instruction (can't be executed in transactions at all, can't be executed in transactions on this particular processor) or by a memory protection fault (access to NULL), etc?...

Could you use an exception handler? If Yes,an exception code could help to understand what really happened.
For example:

...
0x80000001 - Guard Page Violation
0xC0000005 - Access Violation
0xC0000006 - In Page Error
0xC000001D - Illegal Instruction
...

Questions about TSX

jimdempseyatthecove — Fri, 10 Feb 2012 16:37:39 GMT

>>Feedback and introspection seem to be critical for such systems; is it possible to get to know as to whether the abort was caused by a bad instruction (can't be executed in transactions at all, can't be executed in transactions on this particular processor) or by a memory protection fault (access to NULL), etc?

If you write the abort path correctly the memory protection fault should be exposed there.

For "bad instruction" I think this warrants a status bit (one of the remaining 23:6 bits in eax/rax).

However, even without this bit you can still write initialization code to test for support. Example, init code run by one thread testsfunction with RTM once or several times,if function always aborts then assume it will never succeed, and therefore set flag or change function dispatchto usealternate pathwhich uses older lock/unlock structure.

--- revision ---

If an unsupported (bad) instruction occures (say in the test code) bit 1 should not be set (indicating retry will not succeed)

Jim Dempsey

Questions about TSX

jimdempseyatthecove — Fri, 10 Feb 2012 18:11:10 GMT

TSX feature request/query

Consider a processor, say 8 core with HT (16 threads).

Consider maskable interrupts that are not masked OFF.

Any one of these hardware threads could acquire the responsibility of servicing the maskable interrupt.
It would be unfortunate for a hardware thread within an RTM to service the interrupt, should at the time of the interrupt there be a thread (not masked out) that is capable of servicing the interrupt and which is not in RTM.

The feature request is for the selection chriteria as to which thread processes the interrupt first applies to threads not in RTM. Should the case be all threads in RTM then the preferred choice would be the last thread to enter RTM. This feature would conserve on number of retries.

Jim Dempsey

Questions about TSX

Dmitry_Vyukov — Thu, 23 Feb 2012 10:49:38 GMT

I believe that TSX suppresses all relevant exceptions.

By "bad instruction" I meant not an illegal instruction, but an instruction that can't be executed in a transaction (unconditionally causes it to abort).

Questions about TSX

Dmitry_Vyukov — Thu, 23 Feb 2012 10:54:32 GMT

>If an unsupported (bad) instruction occures (say in the test code) bit 1 should not be set (indicating retry will not succeed)

Well, yes, it should be enough to dynamically dispatch to another code path. But it may be not enough for human analysis of what happens and why it happens and how to avoid aborts.

Hi,

Roman_D_Intel — Wed, 12 Sep 2012 09:02:28 GMT

Hi, There is an Intel Developer Forum 2012 presentation on Intel(r) Transactional Synchronization Extensions discussing implementation details. The slides can be downloaded in the technical session catalog: https://intel.activeevents.com/sf12/scheduler/catalog.do or http://intel.com/go/idfsessions (session ARCS004). Best regards, Roman

I posted a blog about

Roman_D_Intel — Thu, 08 Nov 2012 09:02:20 GMT

I posted a blog about "Exploring Intel® Transactional Synchronization Extensions with Intel® Software Development Emulator" Roman