Deconstructing Transactions: The Subtleties of Atomicity Colin Blundell, E Christopher Lewis, Milo M. K. Martin University of Pennsylvania {blundell, lewis,

Slides:



Advertisements
Similar presentations
Memory Consistency Models Kevin Boos. Two Papers Shared Memory Consistency Models: A Tutorial – Sarita V. Adve & Kourosh Gharachorloo – September 1995.
Advertisements

(C) 2001 Daniel Sorin Correctly Implementing Value Prediction in Microprocessors that Support Multithreading or Multiprocessing Milo M.K. Martin, Daniel.
Previously… Processes –Process States –Context Switching –Process Queues Threads –Thread Mappings Scheduling –FCFS –SJF –Priority scheduling –Round Robin.
Background Concurrent access to shared data can lead to inconsistencies Maintaining data consistency among cooperating processes is critical What is wrong.
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
1 Mutual Exclusion: Primitives and Implementation Considerations.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Thread-Level Transactional Memory Decoupling Interface and Implementation UW Computer Architecture Affiliates Conference Kevin Moore October 21, 2004.
1 Beyond Reduction Busy Acquire atomic void busy_acquire() { while (true) { if (CAS(m,0,1)) break; } } if (m == 0) { m = 1; return true; } else.
Synchronization. Shared Memory Thread Synchronization Threads cooperate in multithreaded environments – User threads and kernel threads – Share resources.
1 Lecture 21: Transactional Memory Topics: consistency model recap, introduction to transactional memory.
[ 1 ] Agenda Overview of transactional memory (now) Two talks on challenges of transactional memory Rebuttals/panel discussion.
1 Lecture 7: Transactional Memory Intro Topics: introduction to transactional memory, “lazy” implementation.
1 Lecture 23: Transactional Memory Topics: consistency model recap, introduction to transactional memory.
Simple, Fast, and Practical Non- Blocking and Blocking Concurrent Queue Algorithms Presenter: Jim Santmyer By: Maged M. Micheal Michael L. Scott Department.
Computer Architecture II 1 Computer architecture II Lecture 9.
TxLinux: Using and Managing Hardware Transactional Memory in an Operating System Christopher J. Rossbach, Owen S. Hofmann, Donald E. Porter, Hany E. Ramadan,
1 Sharing Objects – Ch. 3 Visibility What is the source of the issue? Volatile Dekker’s algorithm Publication and Escape Thread Confinement Immutability.
Department of Computer Science Presenters Dennis Gove Matthew Marzilli The ATOMO ∑ Transactional Programming Language.
Hardware solutions So far we have looked at software solutions for the critical section problem. –algorithms whose correctness does not rely on any other.
Simple, Fast and Practical Non- Blocking and Blocking Concurrent Queue Algorithms Maged M. Michael & Michael L. Scott Presented by Ahmed Badran.
1 Lecture 22: Synchronization & Consistency Topics: synchronization, consistency models (Sections )
Synchronization CSCI 444/544 Operating Systems Fall 2008.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
Memory Consistency Models Some material borrowed from Sarita Adve’s (UIUC) tutorial on memory consistency models.
1 Thread Synchronization: Too Much Milk. 2 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing.
CS510 Concurrent Systems Introduction to Concurrency.
Memory Consistency Models Alistair Rendell See “Shared Memory Consistency Models: A Tutorial”, S.V. Adve and K. Gharachorloo Chapter 8 pp of Wilkinson.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Internet Software Development Controlling Threads Paul J Krause.
11/18/20151 Operating Systems Design (CS 423) Elsa L Gunter 2112 SC, UIUC Based on slides by Roy Campbell, Sam.
JAVA MEMORY MODEL AND ITS IMPLICATIONS Srikanth Seshadri
Transactional Memory Lecturer: Danny Hendler. 2 2 From the New York Times…
Shared Memory Consistency Models. SMP systems support shared memory abstraction: all processors see the whole memory and can perform memory operations.
Chapter 7 -1 CHAPTER 7 PROCESS SYNCHRONIZATION CGS Operating System Concepts UCF, Spring 2004.
Memory Consistency Models. Outline Review of multi-threaded program execution on uniprocessor Need for memory consistency models Sequential consistency.
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
DeNovoSync: Efficient Support for Arbitrary Synchronization without Writer-Initiated Invalidations Hyojin Sung and Sarita Adve Department of Computer Science.
Multiprocessor Cache Consistency (or, what does volatile mean?) Andrew Whitaker CSE451.
1 Concurrent Processes. 2 Cooperating Processes  Operating systems allow for the creation and concurrent execution of multiple processes  concurrency.
Memory Consistency Zhonghai Lu Outline Introduction What is a memory consistency model? Who should care? Memory consistency models Strict.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-5 Process Synchronization Department of Computer Science and Software.
© 2008 Multifacet ProjectUniversity of Wisconsin-Madison Pathological Interaction of Locks with Transactional Memory Haris Volos, Neelam Goyal, Michael.
CS533 Concepts of Operating Systems Jonathan Walpole.
Lecture 4 Introduction to Promela. Promela and Spin Promela - process meta language G. Holzmann, Bell Labs (Lucent) C-like language + concurrency dyamic.
CS510 Concurrent Systems Jonathan Walpole. Introduction to Concurrency.
December 1, 2006©2006 Craig Zilles1 Threads & Atomic Operations in Hardware  Previously, we introduced multi-core parallelism & cache coherence —Today.
Lecture 20: Consistency Models, TM
Maurice Herlihy and J. Eliot B. Moss,  ISCA '93
Transactional Memory : Hardware Proposals Overview
Synchronization.
Memory Consistency Models
Department of Computer Science, University of Rochester
Atomic Operations in Hardware
Atomic Operations in Hardware
Memory Consistency Models
Shared Memory Consistency Models: A Tutorial
Lecture: Consistency Models, TM
Christopher J. Rossbach, Owen S. Hofmann, Donald E. Porter, Hany E
Part 1: Concepts and Hardware- Based Approaches
Lecture 22: Consistency Models, TM
Lecture: Consistency Models, TM
CSE 451: Operating Systems Autumn 2003 Lecture 7 Synchronization
CSE 451: Operating Systems Autumn 2005 Lecture 7 Synchronization
CSE 451: Operating Systems Winter 2003 Lecture 7 Synchronization
Lecture: Consistency Models, TM
Problems with Locks Andrew Whitaker CSE451.
Controlled Interleaving for Transactions
Presentation transcript:

Deconstructing Transactions: The Subtleties of Atomicity Colin Blundell, E Christopher Lewis, Milo M. K. Martin University of Pennsylvania {blundell, lewis,

[ 2 ] Converting a Lock-Based Queue enqueue(Q, v){ Node_t node = malloc(…); node->val = v; node->next = NULL; acquire(Q->lock); if (Q->tail) Q->tail->next = node; else Q->head = node; Q->tail = node; release(Q->lock); } dequeue(Q){ int ret = -1; acquire(Q->lock); if (Q->head) Node_t temp = Q->head; ret = temp->val; Q->head = temp->next; free(*temp); release(Q->lock); return ret; }

[ 3 ] Converting a Lock-Based Queue enqueue(Q, v){ Node_t node = malloc(…); node->val = v; node->next = NULL; begin_transaction(); if (Q->tail) Q->tail->next = node; else Q->head = node; Q->tail = node; end_transaction(); } dequeue(Q){ int ret = -1; begin_transaction(); if (Q->head) Node_t temp = Q->head; ret = temp->val; Q->head = temp->next; free(*temp); end_transaction(); return ret; } Translation enhances concurrency, retains safety

flagA, flagB = false; Thread1 Thread2 [ 4 ] Another Example acquire(m->lock); flagA = true; while (!flagB) {} //update m release(m->lock); acquire(n->lock); while (!flagA) {} flagB = true; //update n release(n->lock); Key: m->lock  n->lock

flagA, flagB = false; Thread1 Thread2 [ 5 ] Program Execution acquire(m->lock); flagA = true; while (!flagB) {} //update m release(m->lock); acquire(n->lock); while (!flagA) {} flagB = true; //update n release(n->lock); Time spin

flagA, flagB = false; Thread1 Thread2 [ 6 ] Converting this Program to Transactions begin_transaction(); flagA = true; while (!flagB) {} //update m end_transaction(); begin_transaction(); while (!flagA) {} flagB = true; //update n end_transaction(); Transactions must appear atomic to each other… Time    So one must commit first

flagA, flagB = false; Thread1 Thread2 [ 7 ] Program Execution: Thread2 First begin_transaction(); flagA = true; while (!flagB) {} //update m end_transaction(); begin_transaction(); while (!flagA) {} flagB = true; //update n end_transaction(); Time Thread1 must commit first

flagA, flagB = false; Thread1 Thread2 [ 8 ] Program Execution: Thread1 First begin_transaction(); flagA = true; while (!flagB) {} //update m end_transaction(); begin_transaction(); while (!flagA) {} flagB = true; //update n end_transaction(); Thread1 must commit first Thread2 must commit first Cycle  deadlock Time

[ 9 ] Summary acquire(m->lock); flagA = true; while (!flagB) {} //update m release(m->lock); acquire(n->lock); while (!flagA) {} flagB = false; //update n release(n->lock); Lock  transaction conversion not always safe Promise: benign data races not important flag1, flag2 = false; Thread1 Thread2 begin_transaction(); flagA = true; while (!flagB) {} //update m end_transaction(); begin_transaction(); while (!flagA) {} flagB = false; //update n end_transaction(); flag1, flag2 = false; Thread1 Thread2 

[ 10 ] Agenda Transactions Can Break Lock-Based Code Why Critical Sections Aren’t Transactions Transactions and Non-Transactional Code Takeaway Points

flagA, flagB = false; Thread1 Thread2 [ 11 ] Why Did This Example Go Wrong? (1) acquire(m->lock); flagA = true; while (!flagB) {} //update m release(m->lock); acquire(n->lock); while (!flagA) {} flagB = false; //update n release(n->lock); Time spin Critical sections: atomic wrt others guarded by same lock

flagA, flagB = false; Thread1 Thread2 [ 12 ] Why Did This Example Go Wrong? (2) begin_transaction(); flagA = true; while (!flagB) {} //update m end_transaction(); begin_transaction(); while (!flagA) {} flagB = false; //update n end_transaction(); Time spin  Critical sections: atomic wrt others guarded by same lock Transactions: atomic wrt all other transactions Strengthening atomicity can disallow necessary interleavings (1)

[ 13 ] A More Realistic Example queueA->enqueue(val1); while (queueB->empty()){} //access queueB queueB->enqueue(val2); while (queueA->empty()){} //access queueA Thread1 Thread2 Thread1 and Thread2 mutual producer/consumers

[ 14 ] A More Realistic Example acquire(m->lock);... queueA->enqueue(val1); while (queueB->empty()){} //access queueB... release(m->lock); acquire(n->lock);... queueB->enqueue(val2); while (queueA->empty()){} //access queueA... release(n->lock); Convert to transactions: program breaks As promised, no data races Thread1 Thread2 Queue* queueA = new Queue(); Queue* queueB = new Queue();

[ 15 ] Transactions  Critical Sections Implications Lock  transaction conversion not always safe Intuition about locks may be invalid for transactions Impact on previous proposals No proposed conversion safe Exception: TLR OK in current form Lock-based programs Converted versions Assumption Reality

[ 16 ] Transactions and Non-Transactional Code begin_transaction(); if (x != 0) z = y/x; end_transaction(); x = 0; Thread1Thread2

[ 17 ] Transactions and Non-Transactional Code begin_transaction(); if (x != 0) z = y/x; end_transaction(); x = 0; Q: Is this interleaving legal? A: “We leave undefined the issue of interaction between transactions and non-transactional code.” [Herlihy & Moss, ICSA ‘93] Time Thread1Thread2

[ 18 ] Defining Terms Weak atomicity: transactions are not atomic with respect to non-transactional accesses Strong atomicity: transactions are atomic with respect to non-transactional accesses

[ 19 ] Previous Proposals’ Choices Hardware proposals: mostly strong atomicity Software proposals: mostly weak atomicity Reason: varying cost of strong atomicity HW: cheap if leveraging cache coherence protocol SW: potentially expensive What about semantic implications? Does strong atomicity subsume weak?

[ 20 ] Our Final Example while (!flagA){} flagB = true;... begin_transaction(); flagA = true; while (!flagB){}... end_transaction(); flagA, flagB = false; Thread1 Thread2

[ 21 ] Execution with Weak Atomicity while (!flagA){} flagB = true;... begin_transaction(); flagA = true; while (!flagB){}... end_transaction(); Thread1 Thread2 spin Program executes correctly Time flagA, flagB = false;

[ 22 ] Execution with Strong Atomicity while (!flagA){} flagB = true;... begin_transaction(); flagA = true; while (!flagB){} end_transaction(); Thread1 Thread2 spin Thread1: loops until Thread2 commits Thread2: can’t commit until Thread1 breaks out of its loop Cycle  deadlock Time flagA, flagB = false;

[ 23 ] Strong Atomicity  Weak Strong and weak atomicity are incomparable System’s interface should specify policy Differing policies harm portability Strengthening atomicity can disallow necessary interleavings (2) Weak atomicity Strong atomicity Assumption Reality

[ 24 ] Conclusions 1.Surprise: Transactions do not subsume critical sections Locks: direct conversion to transactions not safe Transactions: lock-based intuition may be invalid 2.Need discussion on policies re: transactions & N-T code Define terms: strong & weak atomicity (or others…) 3.Surprise: Strong atomicity does not subsume weak Affects portability of transactional programs Transparently strengthening atomicity can break correct programs

[ 25 ]