Kayvon's answer to the question "how are isolation and serialization different":

Isolation is the property that no memory updates by a transaction are visible to any other thread until the transaction completes. Or in other words, all operations occur at once, when the transaction completes. Serialization is the property that the output of the program is such that all transactions by all threads can be put in a serialized order on a timeline. Consider a case where transaction 1 is {readA, writeA, writeB} and transaction 2 is {readA, readB, and readC}. Without serialization T2 could read the value of A prior to T1, read the value of B after T1. So the output stored to C by T2 is dependent on A before T1 and B after T1. There's no happens before relationship between T1 and T2.

A transaction is just an abstraction: it is a form of looking at concurrency that satisfies these four constraints which are useful for the programmer, but gives you less fine grained control over locks (illustrated later).

The atomicity reminds me of Solidity programming, where if a transaction fails, it's as if the transaction never happened. This is a useful abstraction for the programmer. How is atomic optimized for runtime under the hood, while achieving all of these four properties?

On a related note, in the database world, transactions are meant to be ACID (Atomic, Consistent, Isolated, and Durable). Interestingly, while serializability here maps to being consistent, there is no notion of thread memory transactions being durable (persistent even after the program terminates or power is lost suddenly). This is because all updates are ultimately made to main memory, not to disk/persistent storage, and main memory is usually volatile and non-persistent.

A lot of the terminology and semantics here of transactions reminds me of how GitHub works (i.e. memory transactions are code commits, isolation is much like a branch, and serializiability is met when branches are merged). Its helpful for me to think about transactional memory in this context.