Andy Glew's comp-arch.net wiki, http://semipublic.comp-arch.net

If you are reading this elsewhere, e.g. at site waboba.info, it is an unauthorized copy, and probably a malware site.
comp-arch.net wiki on hold from October 17, 2011

From CompArch

Pseudo-atomic is a term that I (Glew) have coined to refer to atomic operations that can fail to be atomic, such as:

• Load-linked/store-conditional (LL/SC)
• IBM z196's LOAD PAIR DISJOINT
• even hardware transactional memory
  • such as Intel Transactional Synchronization Extensions (TSX)'s Restricted Transactional Memory (RTM), where "the XBEGIN instruction takes an operand that provides a relative offset to the fallback instruction address if the RTM region could not be successfully executed transactionally."

Q: what does IBM transactional memory provide? Is it pseudo-atomic, or does it provide guarantees?

I.e. these pseudo-atomic operations do not guarantee completion. At least not at the instruction level. While it is possible to imagine implementations that detect use of pseudo-atomic instruction sequences and provide guarantees that certain code sequences will eventually complete. such mechanisms are (1) not necessarily architectural and (2) more complicated that non-pseudo-atomic instructions.

E.g. for LL/SC hardware could "pick up" the instructions that lie between the load-linked and the store-conditional, and map them onto a vocabulary of atomic instructions such as fetch-and-op that is supported by the memory subsystem. Similarly, LL/SC might be implemented using transactional memory (TM).

Intel's TSX documentation says:

RTM instructions do not have any data memory location associated with them. While the hardware provides no guarantees as to whether an RTM region will ever successfully commit transactionally, most transactions that follow the recommended guidelines (See Section 8.3.8) are expected to successfully commit transactionally. However, programmers must always provide an alternative code sequence in the fallback path to guarantee forward progress. This may be as simple as acquiring a lock and executing the specified code region non-transactionally. Further, a transaction that always aborts on a given implementation may complete transactionally on a future implementation. Therefore, programmers must ensure the code paths for the transactional region and the alternative code sequence are functionally tested.

GLEW OPINION: requiring alternate code paths has historically been a bad idea. E.g. Intel Itanium ALAT. Now RTM (Restricted Transactional Memory)

Why, then, provide pseudo-atomicity?

• Pseudo-atomic operations allow complicated atomic operations to be built up out of existing simpler operations
• Plus, of course, it is easier than providing real atomicity. Most of the time it works. Most of the time may be good enough for many people, who may not care if it occasionally crashes when the seldom used alternate path is exercised.