Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Dmitry_Vyukov
Valued Contributor I
40 Views

Questions about TSX

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
0 Kudos
7 Replies
SKost
Valued Contributor II
40 Views

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
...
jimdempseyatthecove
Black Belt
40 Views

>>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
jimdempseyatthecove
Black Belt
40 Views

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
Dmitry_Vyukov
Valued Contributor I
40 Views

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).
Dmitry_Vyukov
Valued Contributor I
40 Views

>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.
Roman_D_Intel
Employee
40 Views

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
Roman_D_Intel
Employee
40 Views