Lecture 17: Transactional Memory 2

What this lecture covers

This lecture continues directly from the first transactional memory lecture, moving from the abstract properties of transactions (atomicity, isolation, serializability) to concrete implementations. It covers a representative software transactional memory (STM) algorithm in detail, then shows how the same ideas map onto hardware by extending cache coherence, and closes with why hardware transactional memory has not seen wide commercial adoption. In its last few minutes it briefly opens the course's next topic, heterogeneous processors.

Watching the first transactional memory lecture first is essential, since this one assumes familiarity with eager versus lazy data versioning, pessimistic versus optimistic conflict detection, and read/write sets. After watching, you should be able to describe how a software TM system tracks transaction state, walk through a hardware TM design built on cache coherence bits, and explain why real systems tend to use transactional memory only in narrow, localized components rather than throughout an application.

Key ideas

• Software barriers: an STM compiler rewrites ordinary reads and writes inside an atomic region into calls like TM_read and TM_write that perform the bookkeeping needed to track transaction state; code that runs both inside and outside transactions needs separate instrumented and uninstrumented versions.
• Transaction descriptor and transaction record: per-thread state (undo log, write buffer, read/write sets) is kept in a transaction descriptor, while per-data metadata (locked or version number) is kept in a transaction record, directly analogous to per-cache-line coherence state.
• Granularity tradeoff: tracking transaction records per object is cheap but can cause false conflicts between transactions touching different fields of the same object; tracking per field or per address reduces false conflicts but adds overhead.
• McRT-style STM: a representative algorithm that is eager for writes (write directly to memory, keep an undo log, and take a lock) but optimistic for reads (read without locking, then validate later), using a global commit timestamp and per-transaction local timestamp to detect conflicts.
• Hardware transactional memory (HTM): reuses the existing cache and coherence protocol to avoid needing explicit software barriers, adding per-cache-line read (R) and write (W) bits, so ordinary coherence traffic (shared or exclusive requests) can be checked against those bits to detect conflicts.
• HTM data versioning: a typical hardware design is lazy (writes stay isolated in the local cache, uncommitted) and optimistic (conflicts are only exposed when the transaction commits and broadcasts an upgrade), because participation in the coherence protocol is deferred until commit.
• Why hardware TM struggled: Intel's hardware TM support saw poor software support, aborted more often than necessary, and was ultimately withdrawn after being used as a side-channel security exploit; commercial use of transactional memory today is mostly software-based and localized to specific data structures rather than applied system-wide.

Walkthrough

Software transactional memory and instrumentation (4:08)

The lecture opens the implementation discussion by showing how a compiler or runtime rewrites code inside an atomic region: every read becomes a call into the transactional memory system (a software barrier) and every write does the same, so the system can perform bookkeeping such as validating data and tracking read/write sets. Because this instrumented code differs from ordinary code, a function used both inside and outside transactions typically needs two versions, sometimes generated automatically through function cloning in managed runtimes like Java.

Tracking transaction state: descriptors, records, and granularity (7:12)

Two data structures track everything an STM needs: a transaction descriptor per thread, holding the undo log, write buffer, and read/write sets, and a transaction record per piece of tracked data, holding metadata such as whether it's locked or its version number, paralleling how a cache line's coherence state works. The lecture works through the tradeoff between tracking this metadata per object (lower overhead but more false conflicts, since unrelated fields on the same object appear to conflict) versus per field or per address (fewer false conflicts, more overhead), noting that real systems often mix granularities, such as per-object for objects and per-element for arrays.

The McRT algorithm: optimistic reads, pessimistic writes (13:15)

The lecture presents Intel's McRT algorithm as a concrete STM design: eager data versioning with optimistic reads and pessimistic writes. A global timestamp increments whenever any transaction commits, and each transaction gets a local timestamp when it begins; a transaction record's low bit distinguishes a locked state (pointing to the owning transaction) from an unlocked state carrying a version number. STM_read reads memory directly, checks the record is unlocked and its version is not newer than the transaction's local timestamp, and otherwise re-validates the whole read set. STM_write pessimistically acquires a lock on the data, records the old value in an undo log, and writes the new value in place immediately, since versioning is eager.

Worked example of the STM algorithm (24:24)

Using two transactions that copy one object's fields to another and then read the result, the lecture traces through reads entering the read set with their observed timestamps, a write acquiring a lock and logging the old value, and a second transaction stalling when it encounters data locked by the first. After the first transaction validates its read set and commits (incrementing the timestamp by two, reserving the low bit for the lock flag), the stalled transaction resumes, but its earlier read set fails re-validation because the data changed underneath it, forcing it to abort and re-execute with fresh reads.

STM performance overhead (34:54)

Benchmark data on hashmap and tree-map workloads shows unoptimized STM barriers adding 70-80% overhead on a single processor compared to non-thread-safe code, but compiler optimizations that eliminate redundant bookkeeping inside the barriers cut that down to roughly 30-40% overhead relative to coarse-grain locking, which itself doesn't scale across processors the way transactions can. The instructor stresses that the fair comparison is against the cost of making code thread-safe at all, not against unsynchronized code that couldn't run in parallel correctly in the first place.

Hardware transactional memory built on cache coherence (42:06)

Hardware TM avoids explicit software barriers entirely: ordinary loads and stores are transparently tracked by extending each cache line's coherence state with read (R) and write (W) bits, and the cache itself serves as the undo log or write buffer while a checkpoint of register state supports aborting back to the start of a transaction. Conflict detection reuses coherence messages: a shared (read) request arriving for a line with the W bit set signals a read-write conflict, an exclusive (write) request for a line with the R bit set signals a write-read conflict, and an exclusive request for a line already marked W signals a write-write conflict. The lecture works through a load/load/store example and a bus-based multi-transaction scenario to show that this design is lazy (writes stay local until commit) and optimistic (conflicts surface only through the coherence broadcast at commit time), classifying it directly using the same lazy/eager and optimistic/pessimistic vocabulary from the STM discussion.

Why hardware TM struggled, and a preview of heterogeneity (1:06:38)

Intel shipped hardware transactional memory instructions, but the lecture explains that software support lagged, transactions aborted more often than necessary, and the feature was ultimately withdrawn after being exploited as a security side channel; the instructor notes Intel's ISA manual still defines the instructions even though current chips don't implement them. Commercial use of transactional memory today, the lecture notes, is mostly software-based and applied narrowly, such as inside specific database components, rather than across an entire parallel system, partly because full STM adoption requires compiler support and code cloning that make a system less general. In its final minutes, the lecture opens the course's next topic by noting that modern CPUs like Intel's Skylake are already heterogeneous, combining general-purpose cores with integrated GPUs and media units, and previews a discussion of how to program across such specialized components.

Before you watch

• Watch the first transactional memory lecture first; this one directly assumes its coverage of atomicity, isolation, serializability, eager vs. lazy versioning, and pessimistic vs. optimistic conflict detection.
• Review the cache coherence (MSI/MESI) lectures, since the hardware TM design is presented as a direct extension of the coherence protocol.

Check your understanding

1. Why does the McRT algorithm treat reads optimistically but writes pessimistically, and what does each choice cost or save?
2. What is a false conflict, and how does choosing per-field instead of per-object transaction records reduce it?
3. In the hardware TM design, what do the per-cache-line R and W bits represent, and how are they used to detect a write-write conflict?
4. Why is a typical hardware transactional memory design classified as lazy and optimistic?
5. What two factors does the lecture give for why hardware transactional memory has not become widely used in commercial processors?