1. Hardware and Software transactional memory and usages in MRE
Salishev S.I.

2. Transactions in Memory
Memory transaction is the unitary set of memory accesses
Memory transaction is similar to DB transaction, similar ACID props
Atomicity
requires that each transaction is "all or nothing": if one part of the transaction fails, the entire transaction fails, and the memory state is left unchanged
Consistency
ensures that any transaction will bring the data in memory from one valid state to another
Isolation
ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e. one after the other
Durability (Optional)
Memory is changed only by transactions

3. Transactions vs. Locks Transactions Locks Speculative + - Safe Nesting
Deadlocks
Overhead
More
Less

4. Transactions and Objects
Natural meaning of transactions in asynchronous actor model
Transaction
Atomic service provided by actor object
Consistency, Isolation
Guarantee of object Encapsulation
Nested Transaction
Call to owned object service

5. Software Transactional Memory
Software implementation of memory transactions
Implementation is based on Read/Write barriers
Control on code side effects
Transaction abortion is programmatically controlled
Sequential consistency is expected by programmers
Problems with reads and data consistency
All reads to transactional variables wrapped in transactions
Implementation
Automatic transactions on all memory accesses
Tremendous performance overhead
Explicit transactional variable markup
Additional work
Error prone

6. Hardware Transactional Memory
Extension to MESI cache coherence protocol
All memory accesses are transactional
Sporadic abortion due to exhausted resources
Supported in commercial products
Azul Systems Vega 2
Intel Haswell
IBM Power8
IBM zEC12
IBM BlueGene/Q

7. Architecture comparison
Nakaike, Takuya, et al. "Quantitative comparison of hardware transactional memory for Blue
Gene/Q, zEnterprise EC12, Intel Core, and POWER8." Proceedings of the 42nd Annual
International Symposium on Computer Architecture. ACM, 2015.

8. MESI Protocol

9. Intel Transactional Synchronization Extensions (TSX)
Haswell implements an unordered, single version, nested TM with strong isolation.
The TM tracks the read-set and write-set at a fixed 64B cache line granularity.
Hardware Lock Elision (HLE)
Backward compatible instruction prefixes, which allow speculative execution of critical sections
Restricted Transactional Memory (RTM)
New synchronization instructions with transactional memory semantics

10. Hardware Lock Elision (HLE)
Acquiring and Releasing a lock are atomic memory write operations
ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCHG8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG
These operations have LOCK (0xF0) prefix
Two new prefixes are provided XACQUIRE and XRELEASE
These two prefixes reuse REPNE / REPE prefixes (F2H / F3H)
These prefixes were ignored on these opcodes before Haswell
XACQUIRE
starts the transaction
adds lock address to read-set
XRELEASE
Commits the transaction
If transaction aborts it is automatically restated without XACQUIRE

11. Restricted Transactional Memory (RTM)
RTM is a full programmatic assess to the underlying TM
XBEGIN offs
Starts the transaction, offs is the abort handler relative address
XEND
Commits the transaction
XABORT im8
Aborts the transaction returns error code
XTEST
Tests if the transaction is executed

12. Transaction Abort Results
EAX Register Bit Position
Meaning
Set if abort caused by XABORT instruction. 1
If set, the transaction may succeed on a retry. This bit is always clear if bit 0 is set. 2
Set if another logical processor conflicted with a memory address that was part of the transaction that aborted. 3
Set if an internal buffer overflowed. 4
Set if debug breakpoint was hit. 5
Set if an abort occurred during execution of a nested transaction.
23:6
Reserved.
31:24
XABORT argument (only valid if bit 0 set, otherwise reserved).

13. HTM Limitations Transaction abort due to resource exhaustion
Non-conflicting Transactions not guarantied to complete
Always need non-HTM fallback
False sharing
All data in the same cache line is considered atomic
False sharing on structure fields and bit fields commonly used in OS’es and File Systems
Cache misses due to postponed transaction commit
Cannot evict data not committed by transaction
Uncommitted data resides in cache taking cache space

14. HTM Software support HTM-Lock HTM-STM Library
HTM transaction with lock based fallback
HTM is used for speculative execution of critical sections
Lock semantics of user code
No transaction support in programming language required
Commonly used in Java
HTM-STM Library
STM transactions with HTM fast-path
STM Library semantics of user code
Transactional data access through library calls or pragmas
transactional_read, transactional_write
#pragma tm_atomic
Only transactional accesses are transaction safe
No durability property
Commonly used in C++
Consistent language STM support with HTM fast-path
All accesses are transaction safe
Durability property
Currently consistent language support is only available in functional languages (Haskell, Clojure)

15. HTM Usages in MRE
Speculative Execution of Critical Sections e.g. Azul Vega 2 JVM
Java Monitors are converted to transactions
Speculative execution of critical sections
On abort the old lock path is executed
No semantic changes, all deadlocks are ours GC
Minimizes synchronization penalty on concurrent reference tracing and updating
Hybrid HTM-STM
Performance optimization of STM
Keeps all implications on changing language semantics