Idit Keidar and Dmitri Perelman Technion 1 SPAA 2009.

Slides:



Advertisements
Similar presentations
Introduction to Database Systems1 Concurrency Control CC.Lecture 1.
Advertisements

Impossibilities for Disjoint-Access Parallel Transactional Memory : Alessia Milani [Guerraoui & Kapalka, SPAA 08] [Attiya, Hillel & Milani, SPAA 09]
Transaction Management: Concurrency Control CS634 Class 17, Apr 7, 2014 Slides based on “Database Management Systems” 3 rd ed, Ramakrishnan and Gehrke.
Chapter 15: Transactions Transaction Concept Transaction Concept Concurrent Executions Concurrent Executions Serializability Serializability Testing for.
Principles of Transaction Management. Outline Transaction concepts & protocols Performance impact of concurrency control Performance tuning.
Presented by: Dmitri Perelman.  Intro  “Don’t touch my read-set” approach  “Precedence graphs” approach  On avoiding spare aborts  Your questions.
IDIT KEIDAR DMITRI PERELMAN RUI FAN EuroTM 2011 Maintaining Multiple Versions in Software Transactional Memory 1.
(c) Oded Shmueli Transactions Lecture 1: Introduction (Chapter 1, BHG) Modeling DB Systems.
Safety Definitions and Inherent Bounds of Transactional Memory Eshcar Hillel.
Inherent limitations on DAP TMs 1 Inherent Limitations on Disjoint-Access Parallel Transactional Memory Hagit Attiya, Eshcar Hillel, Alessia Milani Technion.
1 ICS 214B: Transaction Processing and Distributed Data Management Lecture 6: Cascading Rollbacks, Deadlocks, and Long Transactions Professor Chen Li.
Transactional Contention Management as a Non-Clairvoyant Scheduling Problem Alessia Milani [Attiya et al. PODC 06] [Attiya and Milani OPODIS 09]
Consistency Conditions for STM Sandeep Hans. Agenda Database Consistency Conditions STM Consistency Conditions A different perspective Consistency with.
A Programming Language View of Transactional Memory Hagit Attiya, Technion Joint work with Sandeep Hans, Alexey Gotsman and Noam Rinetzky Published in.
Exploring the relations between STM and DB consistency conditions Sandeep Hans Technion Joint work with Hagit Attiya.
Conflict-Serializability Bharath Kumar Manur Venkataramana Class ID No:- 110.
Presented by: Ofer Kiselov & Omer Kiselov Supervised by: Dmitri Perelman Final Presentation.
DMITRI PERELMAN ANTON BYSHEVSKY OLEG LITMANOVICH IDIT KEIDAR DISC 2011 SMV: Selective Multi-Versioning STM 1.
Submitted by: Omer & Ofer Kiselov Supevised by: Dmitri Perelman Networked Software Systems Lab Department of Electrical Engineering, Technion.
DMITRI PERELMAN IDIT KEIDAR TRANSACT 2010 SMV: Selective Multi-Versioning STM 1.
1 MetaTM/TxLinux: Transactional Memory For An Operating System Hany E. Ramadan, Christopher J. Rossbach, Donald E. Porter and Owen S. Hofmann Presenter:
Distributed Systems Fall 2010 Transactions and concurrency control.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
Algorithmics for Software Transactional Memory Hagit Attiya Technion.
1 Lecture 8: Eager Transactional Memory Topics: implementation details of eager TM, various TM pathologies.
©Silberschatz, Korth and Sudarshan15.1Database System ConceptsTransactions Transaction Concept Transaction State Implementation of Atomicity and Durability.
TM Input Acceptance Vincent Gramoli, Derin Harmanci, Pascal Felber EPFL LPD - University of Neuchâtel Switzerland.
Concurrency. Busy, busy, busy... In production environments, it is unlikely that we can limit our system to just one user at a time. – Consequently, it.
Transaction Processing: Concurrency and Serializability 10/4/05.
1 Lecture 6: TM – Eager Implementations Topics: Eager conflict detection (LogTM), TM pathologies.
Transactions or Concurrency Control. Introduction A program which operates on a DB performs 2 kinds of operations: –Access to the Database (Read/Write)
Transactions. Definitions Transaction (program): A series of Read/Write operations on items in a Database. Example: Transaction 1 Read(C) Read(A) Write(A)
Concurrency. Correctness Principle A transaction is atomic -- all or none property. If it executes partly, an invalid state is likely to result. A transaction,
1 Lecture 7: Lazy & Eager Transactional Memory Topics: details of “lazy” TM, scalable lazy TM, implementation details of eager TM.
CS4432transaction management1 CS4432: Database Systems II Lecture #23 Transaction Management Professor Elke A. Rundensteiner.
An Introduction to Software Transactional Memory
AN OPTIMISTIC CONCURRENCY CONTROL ALGORITHM FOR MOBILE AD-HOC NETWORK DATABASES Brendan Walker.
CMU SCS Carnegie Mellon Univ. Dept. of Computer Science /615 - DB Applications C. Faloutsos – A. Pavlo Lecture#21: Concurrency Control (R&G ch. 17)
Transaction Processing Concepts
Window-Based Greedy Contention Management for Transactional Memory Gokarna Sharma (LSU) Brett Estrade (Univ. of Houston) Costas Busch (LSU) 1DISC 2010.
How Good can a Transactional Memory be? R. Guerraoui, EPFL.
Reduced Hardware NOrec: A Safe and Scalable Hybrid Transactional Memory Alexander Matveev Nir Shavit MIT.
TRANSACTIONS. Objectives Transaction Concept Transaction State Concurrent Executions Serializability Recoverability Implementation of Isolation Transaction.
Chapter 11 Concurrency Control. Lock-Based Protocols  A lock is a mechanism to control concurrent access to a data item  Data items can be locked in.
Chapter 15 Concurrency Control Yonsei University 1 st Semester, 2015 Sanghyun Park.
Concurrency Control Concurrency Control By Dr.S.Sridhar, Ph.D.(JNUD), RACI(Paris, NICE), RMR(USA), RZFM(Germany) DIRECTOR ARUNAI ENGINEERING COLLEGE TIRUVANNAMALAI.
WG5: Applications & Performance Evaluation Pascal Felber
On the Performance of Window-Based Contention Managers for Transactional Memory Gokarna Sharma and Costas Busch Louisiana State University.
Shared Memory Consistency Models. SMP systems support shared memory abstraction: all processors see the whole memory and can perform memory operations.
II.I Selected Database Issues: 2 - Transaction ManagementSlide 1/20 1 II. Selected Database Issues Part 2: Transaction Management Lecture 4 Lecturer: Chris.
Transactional Memory R. Guerraoui, EPFL. Locking is ’’history’’ Lock-freedom is difficult.
Transaction Management Overview. Transactions Concurrent execution of user programs is essential for good DBMS performance. – Because disk accesses are.
1 CSE 480: Database Systems Lecture 24: Concurrency Control.
Timestamp-based Concurrency Control
Multidatabase Transaction Management COP5711. Multidatabase Transaction Management Outline Review - Transaction Processing Multidatabase Transaction Management.
Jinze Liu. ACID Atomicity: TX’s are either completely done or not done at all Consistency: TX’s should leave the database in a consistent state Isolation:
Window-Based Greedy Contention Management for Transactional Memory Gokarna Sharma (LSU) Brett Estrade (Univ. of Houston) Costas Busch (LSU) DISC
6/18/2016Transactional Information Systems3-1 Part II: Concurrency Control 3 Concurrency Control: Notions of Correctness for the Page Model 4 Concurrency.
Transactional Contention Management as a Non-Clairvoyant Scheduling Problem Hagit Attiya, Alessia Milani Technion, Haifa-LABRI, University of Bordeaux.
Maurice Herlihy and J. Eliot B. Moss,  ISCA '93
PHyTM: Persistent Hybrid Transactional Memory
Concurrency Control.
Transactions.
Concurrency Control II (OCC, MVCC)
Lecture 21: Concurrency & Locking
EECS 498 Introduction to Distributed Systems Fall 2017
Distributed Transactions
Lecture 22: Intro to Transactions & Logging IV
Transaction management
Concurrency control (OCC and MVCC)
Presentation transcript:

Idit Keidar and Dmitri Perelman Technion 1 SPAA 2009

 The emergence of multi-core architectures…  Conventional locking…  Transactional Memory is a new synchronization abstraction…  You may continue by yourself 2SPAA 2009

 Aborting transactions is bad:  the work is lost  the resources are wasted  overall throughput decreases  May be even worse:  aborted transactions restart and conflict again  livelock 3SPAA 2009

 Some times aborts are necessary  continuing the run would violate correctness  And some times they are not – spare aborts  the suspicion is unjustified  most of the times based on conflict detection  Our question:  to what degree can we avoid spare aborts? 4SPAA 2009

 Previous measures for evaluating spare aborts and their limitations  Our measures for evaluating spare aborts  Example TM avoiding spare aborts 5SPAA 2009

 Opacity is widely accepted [Guerraoui and Kapalka 08]  Informally: strict serializability, taking into account all the transactions (including the live and aborted ones) 6SPAA 2009

 Previous measures for evaluating spare aborts and their limitations  Our measures for evaluating spare aborts  Example TM avoiding spare aborts 7SPAA 2009

 Commit-Abort Ratio [Gramoli, Harmanci and Felber]: |committed| / (|committed aborted|)  Influenced by the decisions of contention manager  We show: every TM is  (L) competitive in terms of its C-A ratio (L – maximal possible number of live txns)  All TMs are bad in terms of C-A ratio, hard to compare  T1T1 o1 o2 o3 T2T2 CA AAA T1T1 o1 o2 o3 T2T2 CA AAA Which txn to abort? 8SPAA 2009

 TM is p-permissive w.r.t. safety property p if it accepts every history that satisfies p [Guerraoui et al 08]  Our focus: opacity-permissiveness  If the given history does not violate opacity, then the TM should run it without aborts 9SPAA 2009

 We show: there exists no TM providing 0pacity- permissiveness  Intuition: there is a degree of freedom given to the read operations  cannot predict what value should be read in order to avoid spare aborts in future 10SPAA 2009

 Previous measures for evaluating spare aborts and their limitations  Our measures for evaluating spare aborts  Example TM avoiding spare aborts 11SPAA 2009

 Strict Online Opacity-Permissiveness: a TM forcefully aborts a txn only when not aborting any txn violates opacity.  does not define which txns should be aborted  allows returning a value that causes abort in the future  NP-Complete in the number of committed txns   reduction from the view-serializability detection problem [Papadimitriou 79] 12SPAA 2009

 The “problem”: the order of committed txns is undefined T1T1 o1 o2 o3 T2T2 CC T4T4 C C Txns serialization: T4T4 T1T1 T2T2 T3T3 T3T3 ? 13SPAA 2009

 Online opacity-permissiveness (intuition):  order the committed txns writing to the same objects  this order should be preserved during the run 14SPAA 2009

 Visible reads have their cost:  cache invalidations in a multi-core environments  Postpone exposing the read if possible  We show: if a TM satisfies online opacity- permissiveness the reads must be exposed as they happen  o1 o2 T1T1 o1 o2 T1T1 T2T2 A T3T3 T3T3 T4T4 T4T4 15SPAA 2009

 Previous measures for evaluating spare aborts and their limitations  Our measures for evaluating spare aborts  Example TM avoiding spare aborts 16SPAA 2009

 AbortsAvoider algorithm as a possibility proof  Polynomial time operation complexity  Maintains version lists and the precedence graph 17SPAA 2009

 Directed labeled graph over transactions  different variations in prior works [Napper and Alvisi 05, Guerraoui and Kapalka 08]  We show: if a TM maintains PG acyclic and aborts txn only upon cycle creation, then this TM satisfies online opacity- permissiveness o.v n o.v n-1 writer readers WaW RaW WaR 18SPAA 2009

 Reads are simple:  look for the latest version that does not create a cycle in the PG  Writes are simpler than Reads:  postpone the work till commit (invisible writes) 19SPAA 2009

 Install the new versions of all written objects  non-blind writes: after the version that has been read  blind writes: plenty of options  The greedy approach does not work  The places to install are sought in iterations 20SPAA 2009

 Transactions cannot be garbage collected right after the termination  should be kept in PG as long as it has a potential to participate in a cycle  We define GC conditions  from some point onward no new incoming edges will be added to the node  Optimizations to save run-time complexity 21SPAA 2009

 Avoiding spare aborts is not always possible  Avoiding spare aborts may be costly:  no invisible reads for opacity  complicated conditions for GC  Proof-of-concept algorithm avoiding spare aborts with polynomial time complexity  “Spare aborts vs. Operations complexity” tradeoff is yet to be studied 22SPAA 2009

23SPAA 2009