It's official, according to this post on Intel SDN: Haswell, the "tock" of mighty Ivy (née Sandy) Bridge, will feature transactional memory, while maintaining the 22nm Trigate MOSFET process (Intel goes to 14nm with Broadwell in 2014). I didn't really believe in transactional memory when it was first being kicked around; if you know where you need locking, I reasoned, just lock and be done with it. That was before I heard about Speculative Lock Elision (tip of the hat to Jesse Beu, leader of men and killer of ladies) in Prof. Tom Conte's CS8803MCA [0], and the possibilities became apparent (software transactional memory, on the other hand, was and remains a bunch of crap). If you're not yet up-to-speed on TM/STM, check out the TM-101 seminar notes from SPbSU (and, par for the course, avoid the extortionist output of the for-profit scientific press).

The Intel AVX Manual (aka the Intel® Architecture Instruction Set Extensions Programming Reference) has been updated as of 2012-02 to include the new interfaces (collectively known as Intel TSX (aka Intel® Transactional Synchronization Extensions)). The following data are summarized from §8.2 of Intel Ref. № 319433-012:

• Hardware Lock Elision (HLE): Legacy-compatible specification of transactional regions via the XACQUIRE and XRELEASE prefixes. They provide hints to hardware lock elision. Legacy compatibility means that valid code's semantics will not be changed; the two new prefixes occupy the same opcodes as the REPNE/REPE prefixes, and the sets of valid subsequent opcodes are wholly disjoint. Improper use cannot introduce functional bugs. HLE is present when CPUID.07H.EBX.HLE (bit 4) is set.
• Restricted Transactional Memory (RTM): The new XTest, XBEGIN, XEND and XABORT instructions allow for flexible critical section definitions, and require a failure (rollback) path. Software can query the processor state relative to defined transactional sections. RTM support is present when CPUID.07H.EBX.RTM (bit 11) is set, and use of RTM instructions on processors lacking support will generate a #UD exception.

Nested transactions are supported as a single monolithic transaction (an abort restores state at the outermost XACQUIRE-prefixed HLE or XBEGIN instruction). Unfortunately, the nesting is subject to an implementation-defined limit (referred to as MAX_HLE_ELIDED_LOCKS in the Reference), unavailable to application code and not even published in the Reference, at which point the transaction may abort. Argh, not cool! Handling the myriad abort codes will be a minor pain for low-level implementors. Here's a fun game: design a sensible API (assume C++-style exceptions) around Table 8-1:

EAX bits	Meaning
0	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 a 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).

Overall, it seems pretty well-designed. Either way, yet another fun new development from the 256-bit AVX instructions!

0. Prof. David Bader appears to be teaching the class next; here's his 2007 syllabus. From what I can tell, our instance covered a lot more VLSI, optimizing compilation, and true manycore.