6.852 Lecture 23●Transactional memory (continued)●Shared memory vs networks●Paxos●Reading:–Herlihy, Luchangco, Moir, Scherer paper–Dice, Shalev, Shavit paper–Lynch, Chapter 17–Lamport: The Part-Time ParliamentTransactional memory●Raise level of abstraction–programmer specifies atomicity boundaries: transactions–system guarantees atomicity●commits if it can●aborts if not (roll back any changes)●possibly retry on abort–system manages contention (possibly separable functionality)–compositional (due to nested transactions)●but large transactions may not commit–simplified interface: atomic blocks●atomic { code }●automatic retryUsing transactional memoryQ.enqueue(x) node = new Node(x) node.next := null atomic{ oldtail = Q.tail Q.tail := node if oldtail = null then Q.head := node else oldtail.next := node } Q.dequeue() atomic{ if Q.head = null then return null else node := Q.head Q.head := node.next if node.next = null then Q.tail := null return node.item } transfer(Q,Q') atomic{ x = Q.dequeue() if x null then Q'.enqueue(x) }Dynamic STM (DSTM)●object-based (JavaTM library)●no locks (obstruction-free)●supports dynamic allocation and access●separable contention management●pluggable implementations (2nd release)–added blocking “shadow” implementationstartxactionnew objectabortedold objectstartxactionnew objectabortedold objectxactionnew objectactiveold objectstartxactionnew objectabortedold objectxactionnew objectactiveold objectstartxactionnew objectcommitold objectstartxactionnew objectcommitold objectxactionnew objectactiveold objectstartxactionnew objectcommitold objectxactionnew objectactiveold objectstartxactionnew objectactiveold objectactiveEnable “read-sharing”●Invisible readers–keep thread-local “read set”: pairs of location and version read–validation checks no location in read set has changed●Visible readers–keep set of active readers in “locator”●Semi-visible readers–keep number of readersxactionfield 1commitshadow 1field 2shadow 2field 3shadow 3xactionfield 1commitshadow 1field 2shadow 2field 3shadow 3xactionfield 1commitshadow 1field 2shadow 2field 3shadow 3activexactionfield 1shadow 1field 2shadow 2field 3shadow 3activeTransactional Locking II (TL2)●Best (or one of the best) performing STM–also other nice properties beyond the scope of this lecture●Lock-based, word-based STM–locks only held during commit phase (not executing user code)●Uses global version number (potential bottleneck)–updated by each writing transaction (but could relax this)●Every location also has version number–transaction that last wrote itTransactional Locking II (TL2)●Read global version counter–store locally: rv (for read version)●Run transaction “speculatively”–track which locations are read and written–when location first accessed, check version counter–write values into write set–read values into read set (so transaction gets consistent reads)●if value was written by transaction, get value from write set●At commit–lock write set–increment global version counter–validate read set–write-back values–release locksCombining hardware and software●Hardware-assisted transactional memory–new required hardware–hardware support can accelerate implementation●Hybrid transactional memory–STM that can work with HTM ●hardware transactions and software transactions must “play nicely”●can be used now (with no hardware support)●can exploit HTM support with little change–phased transactional memory●can switch dynamically between using STM and HTMShared memory vs networks●Network algorithm to shared memory algorithm–“implement” network using shared memory–easy because shared memory is “stronger” than network–useful primarily for lower bounds (e.g., impossibility of consensus)●Shared memory algorithm to network algorithm–“implement” shared memory over network (DSM)–easy if no failures–impossible if more than n/2 failures–Attiya-BarNoy-Dolev fault-tolerant algorithm●Replicated state machine over network–PaxosNetwork on shared memory●State variables for each i (written by i)–pstatei: states(Pi)–sent(j)i for each out-neighbor j: sequence of M, initially empty–msgs-rcvd(i)j for each in-neighbor j: N, initially 0●Transitions for i–send(m,j)i:●pre: send(m)i,j in pstatei●eff: append m to sent(j)i; update pstatei as for send(m)i,j–receive(m,j)i●pre: |sent(i)j| > msgs-rcvd(j)i; m = sent(i)j[msgs-rcvd(j)i+1]●eff: increment msgs-rcvd(j)i; update pstatei as for receive(m)j,i–all others: precondition/effect as in Pi with state pstateiNetwork on shared memory●Impossibility of consensus on network–with reliable FIFO channels–with reliable broadcast●similar transformationShared memory over network●Assume shared memory system A–n ports; user Ui for i = 1..n interacts with process i on port i –for each i, either user's turn, or process's turn (not both)●so we can use atomic objects instead of shared variables●Design asynchronous network system B–same ports/user interface–execs of B are indistiguishable (to users) from execs of A●and same processes fail (if applicable)●Non-fault-tolerant strategies: single-copy, multiple copy●Impossibility of tolerating majority failures●ABD fault-tolerant algorithm for read/write registersSingle-copy DSM●Each shared variable is “owned” by some process–owner(X) known by all–handle each shared variable independently●All actions other than shared-memory access as before●To invoke op on X, send “inv(op,X)” to owner(X)–wait for response–continue to handle invocation msgs received●Each process applies operations in order received–send response of each operation to appropriate processSingle-copy DSM●Can implement any shared variable type●Location of shared variables●Elimination of busy-waiting–send “condition” to owner–works for multiple variables if they have the same owner●Process stopping means no access to variables it ownsMulticopy DSM●Goal: improve performance of read–maintain several copies–can be good if reading is more common than writing–still no fault tolerance●Concern: “coherence” problems–inconsistency among various copies–problem even for single-writer shared variables●Use transactions to maintain coherence●See book for more detailsImpossibility of