k-abortable Objects: Progress under High Contention
|
|
|
- Elwin Beverly Sparks
- 5 years ago
- Views:
Transcription
1 k-abortable Objects: Progress under High Contention Naama Ben-David 1, David Yu Cheng Chan 2, Vassos Hadzilacos 2, and Sam Toueg 2 Carnegie Mellon University 1 University of Toronto 2
2 Outline Background and Motivation. Define k-abortability. Fast k-abortable universal construction.
3 Outline Background and Motivation. Define k-abortability. Fast k-abortable universal construction.
4 Model: Asynchronous shared memory We have n processes that take steps in shared memory Steps are atomic primitives provided by the system: read/write registers, CAS and LL/SC Goal: Implement high-level objects using these primitives Challenge: asynchronous, and processes may fail by crashing
5 Implementation Requirements An object implementation must be: Linearizable - each operation appears to take effect at a point between its invocation and response. Live
6 Implementation Requirements An object implementation must be: Linearizable - each operation appears to take effect at a point between its invocation and response [HerlihyWing 90]. invocation Linearization point response Live processes make progress A process makes progress if it completes an infinite number of operations in an infinite execution.
7 Implementation Requirements An object implementation must be: Linearizable - each operation appears to take effect at a point between its invocation and response [HerlihyWing 90]. invocation Linearization point response Live: Some processes make progress
8 Liveness: Wait Freedom Every correct process must finish each operation in a finite number of its own steps. So, all correct processes make progress [Herlihy 91]. Requires strong primitives
9 Drawback of Wait Freedom Typically wait freedom requires an expensive helping mechanism. To prevent the starvation of slow processes, a fast process helps slow processes complete their operations. This helping mechanism takes Ω(n) time in the worst-case.
10 Liveness: Lock Freedom At least one process makes progress. Shown to do well in practice. No need for helping mechanism. Up to n-1 processes can get stuck.
11 Liveness: k-lock Freedom At least k processes make progress For k = 1, this is lock freedom, For k = n, this is wait freedom. [BushkovGuerraoui 15] introduced this progress condition but did not give k-lock free implementations for 1 < k < n. Processes can still get stuck.
12 Liveness: Abortability All operations terminate, by completing or aborting. An operation that aborts does not change the state of the object. An operation may abort only if it is concurrent with another operation [HadzilacosToueg 13]. p1 p2
13 Liveness: Abortability All operations terminate, by completing or aborting. An operation that aborts does not change the state of the object. An operation may abort only if it is concurrent with another operation [HadzilacosToueg 13]. Abort! p1 Abort! p2
14 Liveness: Abortability All operations terminate, by completing or aborting. An operation that aborts does not change the state of the object. An operation may abort only if it is concurrent with another operation [HadzilacosToueg 13]. Abort! p1 Abort! p2
15 Liveness: Abortability All operations terminate, by completing or aborting. An operation that aborts does not change the state of the object. An operation may abort only if it is concurrent with another operation [HadzilacosToueg 13]. Abort! p1 Abort! p2
16 Liveness: Abortability All operations terminate, by completing or aborting. An operation that aborts does not change the state of the object. An operation may abort only if it is concurrent with another operation [HadzilacosToueg 13]. Abort! p1 Abort! p2
17 Liveness: Abortability All operations terminate, by completing or aborting. An operation that aborts does not change the state of the object. An operation may abort only if it is concurrent with another operation [HadzilacosToueg 13]. Abort! p1 Abort! p2
18 Outline Background and Motivation Define k-abortability. Fast k-abortable universal construction.
19 Outline Background and Motivation Define k-abortability. Fast k-abortable universal construction.
20 k-abortability Goals k-abortability guarantees: k-lock-freedom: At least k processes make progress, regardless of slow or crashed processes. Abortability: No processes are ever stuck.
21 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations
22 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations But this allows: p1
23 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations But this allows: p1 p2
24 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations But this allows: p1 p2
25 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations But this allows: p1 p2
26 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations But this allows: p1 p2 k operations of p2
27 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations But this allows: p1 p2 Abort! k operations of p2
28 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes But this allows: p1 p2 Abort! k operations of p2
29 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes
30 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: But this allows: p1 are issued by distinct processes
31 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes But this allows: p1 p 2
32 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes But this allows: p1 p 2 p 3
33 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes But this allows: p1 p 2 p 3
34 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes But this allows: p1 p 2 p 3 p k+1
35 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes But this allows: p1 p 2 p 3 p k+1
36 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes do not abort But this allows: p1 p 1 p 2 p k
37 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes do not abort
38 A new liveness property: k-abortability An object implementation is k-abortable if: But this allows: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes do not abort p 1 p 2 Very slow or crashed p k
39 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes do not abort But this allows: p p 1 p 2 Very slow or crashed p k
40 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes do not abort But this allows: p p 1 p 2 Very slow or crashed p k
41 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes do not abort But this allows: p p 1 p 2 Very slow or crashed p k
42 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes do not abort are all linearized within op s interval. But this allows: p p 1 p 2 Very slow or crashed p k
43 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes do not abort are all linearized within op s interval.
44 A new liveness property: k-abortability An object implementation is k-abortable if: No operation op aborts unless it is concurrent with at least k other operations that: are issued by distinct processes do not abort are all linearized within op s interval. k-abortability guarantees: At least k processes make progress, regardless of slow or crashed processes. No processes are ever stuck.
45 Outline Background and Motivation Define k-abortability. Fast k-abortable universal construction.
46 Outline Background and Motivation Define k-abortability. Fast k-abortable universal construction.
47 Data Structures: Record Array p... n
48 Data Structures: Record Array p... n Operation Response p's current operation Record[p] its response, empty if pending
49 Data Structures: Announce Array i... k
50 Data Structures: Announce Array i... k Id Announce[i] which process has taken this slot
51 Data Structures: Core State Id Response Core
52 Data Structures: Core The current state of the implemented object State Id Response Core
53 Data Structures: Core The process whose operation was just done State Id Response Core The current state of the implemented object The response of the operation that was just done
54 Algorithm Outline For process p to perform an operation op:
55 Algorithm Outline For process p to perform an operation op: 1. Record op
56 Algorithm Outline For process p to perform an operation op: 1. Record op p... n Operation = op Response = empty Record[p]
57 Algorithm Outline For process p to perform an operation op: 1. Record op Operation = op... Response = empty 2. Try to announce that p has an operation...
58 Algorithm Outline For process p to perform an operation op: 1. Record op Operation = op Response = empty 2. Try to announce that p has an operation i... k Id = p Announce[i]
59 Algorithm Outline For process p to perform an operation op: 1. Record op 2. Try to announce that p has an operation 3. Help some processes Operation = op... Response = empty... Id = p......
60 Algorithm Outline For process p to perform an operation op: 1. Record op 2. Try to announce that p has an operation 3. Help some processes Operation = op... Response = empty... Id = p Do an announced operation State Id Response Update the core
61 Algorithm Outline For process p to perform an operation op: 1. Record op 2. Try to announce that p has an operation 3. Help some processes Operation = op... Response = empty... Id = p Do an announced operation State Id Response Update the core Relay response to record
62 Algorithm Outline For process p to perform an operation op: 1. Record op 2. Try to announce that p has an operation 3. Help some processes 4. Clean up
63 Achieving k-abortability: Goals If an operation op aborts, there are k operations that:
64 Achieving k-abortability: Goals If an operation op aborts, there are k operations that: 1. are concurrent with op 2. do not abort 3. are invoked by distinct processes 4. are linearized during op
65 The Announcing Procedure Compete over slots of Announce[1..k] sequentially. Record... Id... Announce[1..k]
66 The Announcing Procedure Not enough to search for only empty slots.
67 The Announcing Procedure Not enough to search for only empty slots. Ensure an attempt on slot i fails ONLY IF at some point during attempt,
68 The Announcing Procedure Not enough to search for only empty slots. Ensure an attempt on slot i fails ONLY IF at some point during attempt,... Id = q... Announce[i]
69 The Announcing Procedure Not enough to search for only empty slots. Ensure an attempt on slot i fails ONLY IF at some point during attempt, AND... Id = q... Announce[i]... Operation Response = empty Records[q]... Not yet linearized.
70 The Announcing Procedure Compete over slots of Announce[1..k] sequentially. Record Abort... Id... Announce[1..k]
71 Achieving k-abortability: Goals If an operation op aborts, there are k operations that: 1. are concurrent with op 2. do not abort 3. are invoked by distinct processes 4. are linearized during op
72 Ensuring the properties of k-abortability (1) + (2): If op aborts there are k concurrent operations that do not abort.
73 Ensuring the properties of k-abortability (1) + (2): If op aborts there are k concurrent operations that do not abort. Basic idea: If op aborts, op lost to k operations that won the k slots of the announce array
74 Ensuring the properties of k-abortability (1) + (2): If op aborts there are k concurrent operations that do not abort. Basic idea: If op aborts, op lost to k operations that won the k slots of the announce array Each was announced and had empty response
75 Ensuring the properties of k-abortability (1) + (2): If op aborts there are k concurrent operations that do not abort. Basic idea: If op aborts, op lost to k operations that won the k slots of the announce array Each was announced and had empty response Each was concurrent with op. Each did not abort.
76 Achieving k-abortability: Goals If an operation op aborts, there are k operations that: 1. are concurrent with op 2. do not abort 3. are invoked by distinct processes 4. are linearized during op
77 Ensuring the properties of k-abortability (3): There are k concurrent operations by distinct processes that do not abort. op loses competitions on k slots, so there are k concurrent operations. Problem:
78 Ensuring the properties of k-abortability (3): There are k concurrent operations by distinct processes that do not abort. op loses competitions on k slots, so there are k concurrent operations. Problem: But they could all belong to the same (fast) process!
79 2-Abortable Example op Record Id = q Announce[1..k]
80 2-Abortable Example op Record Id = q Announce[1..k]
81 2-Abortable Example op Record Id =? Id = q Announce[1..k]
82 2-Abortable Example op Record Id =? Id = q Announce[1..k]
83 Ensuring the properties of k-abortability (3): There are k concurrent operations by distinct processes that do not abort. Problem: op loses competitions on k slots, so there are k concurrent operations. But they could all belong to the same (fast) process! Solution: Find a new set of k concurrent operations that do not abort.
84 2-Abortable Example op Record Id =? Id = q Announce[1..k]
85 Ensuring the properties of k-abortability By Induction: Whenever an operation op loses slot i, there are i operations that: are by distinct processes are concurrent with op do not abort
86 Achieving k-abortability: Goals If an operation op aborts, there are k operations that: 1. are concurrent with op 2. do not abort 3. are invoked by distinct processes 4. are linearized during op
87 Ensuring the properties of k-abortability (4): The k operations by distinct processes that do not abort are linearized during op. Idea: Ensure an attempt on slot i fails ONLY IF at some point during attempt, slot i has an announced operation that has not been linearized.
88 The Announcing Procedure Not enough to search for only empty slots. Ensure an attempt on slot i fails ONLY IF at some point during attempt, AND... Id = q... Announce[i]... Operation Response = empty Records[q]... Not yet linearized.
89 Ensuring the properties of k-abortability (4): The k operations by distinct processes that do not abort are linearized during op. Idea: Ensure an attempt on slot i fails ONLY IF at some point during attempt, slot i has an announced operation that has not been linearized. Help k+3 times to linearize all announced operations.
90 Ensuring the properties of k-abortability (4): The k operations by distinct processes that do not abort are linearized during op. Idea: Ensure an attempt on slot i fails ONLY IF at some point during attempt, slot i has an announced operation that has not been linearized. Help k+3 times to linearize all announced operations.?
91 Ensuring the properties of k-abortability (4): The k operations by distinct processes that do not abort are linearized during op. Idea: Ensure an attempt on slot i fails ONLY IF at some point during attempt, slot i has an announced operation that has not been linearized. Help k+3 times to linearize all announced operations. Ensures only the k winners are linearized, not the new set of k operations!
92 Ensuring the properties of k-abortability By Induction: Whenever an operation op loses slot i, there are i operations that: are by distinct processes are concurrent with op do not abort are not linearized before op' is invoked.
93 Ensuring the properties of k-abortability By Induction: Whenever an operation op loses slot i, there are i operations that: are by distinct processes are concurrent with op do not abort are not linearized before op' is invoked. (see paper)
94 Conclusion Defined k-abortability (which is at least as strong as k-lock freedom). Gave a k-abortable universal construction that takes O(k) steps per operation. In paper: use a result of [Jayanti 98] to prove a lower bound of Ω (log k) for k-abortable universal constructions.
95 Conclusion Defined k-abortability (which is at least as strong as k-lock freedom). Gave a k-abortable universal construction that takes O(k) steps per operation. In paper: use a result of [Jayanti 98] to prove a lower bound of Ω (log k) for k-abortable universal constructions. Future: An adaptive k-abortable algorithm?
96 Conclusion Defined k-abortability (which is at least as strong as k-lock freedom). Gave a k-abortable universal construction that takes O(k) steps per operation. In paper: use a result of [Jayanti 98] to prove a lower bound of Ω (log k) for k-abortable universal constructions. Future: An adaptive k-abortable algorithm? Thank you!
97 Appendix
98 Adaptivity Wait free. Time depends on the number of currently active processes j, where 1 j n. Best known universal construction takes O(j).
99 Adaptivity vs k-abortability Adaptivity Everyone makes progress k-abortability n-k allowed to abort Cost ranges from 1 to n Cost stays at k Not mutually exclusive.
100 Liveness: Obstruction Freedom A process completes its operation if it executes alone for a sufficient number of steps. Pro: can be achieved using only read/write registers. Con: if multiple processes execute at the same time, it is possible that no process makes progress: every process may get stuck forever executing an operation.
101 Primitive: LL/VL/SC LL/VL/SC: A variable x. Has x changed since my last LL()? Yes No LL() return x return x VL() return false return true SC(v) return false set x = v return true
102 There are other liveness and related concepts Obstruction freedom Adaptive implementation
k-abortable Objects: Progress Under High Contention
k-abortable Objects: Progress Under High Contention Naama Ben-David 1, David Yu Cheng Chan 2(B), Vassos Hadzilacos 2, and Sam Toueg 2 1 Carnegie Mellon University, Pittsburgh, PA 15213, USA naama@cmu.edu
6.852: Distributed Algorithms Fall, Class 21
6.852: Distributed Algorithms Fall, 2009 Class 21 Today s plan Wait-free synchronization. The wait-free consensus hierarchy Universality of consensus Reading: [Herlihy, Wait-free synchronization] (Another
A class C of objects is universal for some set E of classes if and only if any object in E can be implemented with objects of C (and registers)
Universality A class C of objects is universal for some set E of classes if and only if any object in E can be implemented with objects of C (and registers) n-consensus is universal for n-objects (objects
The Wait-Free Hierarchy
Jennifer L. Welch References 1 M. Herlihy, Wait-Free Synchronization, ACM TOPLAS, 13(1):124-149 (1991) M. Fischer, N. Lynch, and M. Paterson, Impossibility of Distributed Consensus with One Faulty Process,
Non-blocking Array-based Algorithms for Stacks and Queues. Niloufar Shafiei
Non-blocking Array-based Algorithms for Stacks and Queues Niloufar Shafiei Outline Introduction Concurrent stacks and queues Contributions New algorithms New algorithms using bounded counter values Correctness
Non-blocking Array-based Algorithms for Stacks and Queues!
Non-blocking Array-based Algorithms for Stacks and Queues! Niloufar Shafiei! Department of Computer Science and Engineering York University ICDCN 09 Outline! Introduction! Stack algorithm! Queue algorithm!
Concurrent Computing
Concurrent Computing Introduction SE205, P1, 2017 Administrivia Language: (fr)anglais? Lectures: Fridays (15.09-03.11), 13:30-16:45, Amphi Grenat Web page: https://se205.wp.imt.fr/ Exam: 03.11, 15:15-16:45
Implementing caches. Example. Client. N. America. Client System + Caches. Asia. Client. Africa. Client. Client. Client. Client. Client.
N. America Example Implementing caches Doug Woos Asia System + Caches Africa put (k2, g(get(k1)) put (k2, g(get(k1)) What if clients use a sharded key-value store to coordinate their output? Or CPUs use
Allocating memory in a lock-free manner
Allocating memory in a lock-free manner Anders Gidenstam, Marina Papatriantafilou and Philippas Tsigas Distributed Computing and Systems group, Department of Computer Science and Engineering, Chalmers
Computing with Infinitely Many Processes under assumptions on concurrency and participation -M.Merritt&G.Taubenfeld. Dean Christakos & Deva Seetharam
Computing with Infinitely Many Processes under assumptions on concurrency and participation -M.Merritt&G.Taubenfeld Dean Christakos & Deva Seetharam November 25, 2003 Abstract This paper explores four
The Complexity of Renaming
The Complexity of Renaming Dan Alistarh EPFL James Aspnes Yale Seth Gilbert NUS Rachid Guerraoui EPFL Abstract We study the complexity of renaming, a fundamental problem in distributed computing in which
SSC - Concurrency and Multi-threading Java multithreading programming - Synchronisation (II)
SSC - Concurrency and Multi-threading Java multithreading programming - Synchronisation (II) Shan He School for Computational Science University of Birmingham Module 06-19321: SSC Outline Outline of Topics
Constant RMR Transformation to Augment Reader-Writer Locks with Atomic Upgrade/Downgrade Support
Constant RMR Transformation to Augment Reader-Writer Locks with Atomic Upgrade/Downgrade Support Jake Stern Leichtling Thesis Advisor: Prasad Jayanti With significant contributions from Michael Diamond.
Nesting-Safe Recoverable Linearizability: Modular Constructions for Non-Volatile Memory
Nesting-Safe Recoverable Linearizability: Modular Constructions for Non-Volatile Memory Hagit Attiya Department of Computer Science, Technion hagit@cs.technion.ac.il Ohad Ben-Baruch Department of Computer
Section 4 Concurrent Objects Correctness, Progress and Efficiency
Section 4 Concurrent Objects Correctness, Progress and Efficiency CS586 - Panagiota Fatourou 1 Concurrent Objects A concurrent object is a data object shared by concurrently executing processes. Each object
Order Is A Lie. Are you sure you know how your code runs?
Order Is A Lie Are you sure you know how your code runs? Order in code is not respected by Compilers Processors (out-of-order execution) SMP Cache Management Understanding execution order in a multithreaded
Dr. D. M. Akbar Hussain DE5 Department of Electronic Systems
Concurrency 1 Concurrency Execution of multiple processes. Multi-programming: Management of multiple processes within a uni- processor system, every system has this support, whether big, small or complex.
Universality of Consensus. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Universality of Consensus Companion slides for The by Maurice Herlihy & Nir Shavit Turing Computability 1 0 1 1 0 1 0 A mathematical model of computation Computable = Computable on a T-Machine 2 Shared-Memory
CMPSCI 250: Introduction to Computation. Lecture #24: General Search, DFS, and BFS David Mix Barrington 24 March 2014
CMPSCI 250: Introduction to Computation Lecture #24: General Search, DFS, and BFS David Mix Barrington 24 March 2014 General Search, DFS, and BFS Four Examples of Search Problems State Spaces, Search,
Optimal-Time Adaptive Strong Renaming, with Applications to Counting
Optimal-Time Adaptive Strong Renaming, with Applications to Counting [Extended Abstract] Dan Alistarh EPFL James Aspnes Yale University Keren Censor-Hillel MIT Morteza Zadimoghaddam MIT Seth Gilbert NUS
1 The comparison of QC, SC and LIN
Com S 611 Spring Semester 2009 Algorithms for Multiprocessor Synchronization Lecture 5: Tuesday, 3rd February 2009 Instructor: Soma Chaudhuri Scribe: Jianrong Dong 1 The comparison of QC, SC and LIN Pi
arxiv: v8 [cs.dc] 29 Jul 2011
![arxiv: v8 [cs.dc] 29 Jul 2011](/thumbs/93/114368154.jpg "arxiv: v8 [cs.dc] 29 Jul 2011")
On the Cost of Concurrency in Transactional Memory Petr Kuznetsov TU Berlin/Deutsche Telekom Laboratories Srivatsan Ravi TU Berlin/Deutsche Telekom Laboratories arxiv:1103.1302v8 [cs.dc] 29 Jul 2011 Abstract
Programming Paradigms for Concurrency Lecture 3 Concurrent Objects
Programming Paradigms for Concurrency Lecture 3 Concurrent Objects Based on companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Thomas Wies New York University
G52CON: Concepts of Concurrency
G52CON: Concepts of Concurrency Lecture 11: Semaphores I" Brian Logan School of Computer Science bsl@cs.nott.ac.uk Outline of this lecture" problems with Peterson s algorithm semaphores implementing semaphores
Concurrent Objects and Linearizability
Chapter 3 Concurrent Objects and Linearizability 3.1 Specifying Objects An object in languages such as Java and C++ is a container for data. Each object provides a set of methods that are the only way
Fast and Lock-Free Concurrent Priority Queues for Multi-Thread Systems
Fast and Lock-Free Concurrent Priority Queues for Multi-Thread Systems Håkan Sundell Philippas Tsigas Outline Synchronization Methods Priority Queues Concurrent Priority Queues Lock-Free Algorithm: Problems
From Bounded to Unbounded Concurrency Objects and Back
From Bounded to Unbounded Concurrency Objects and Back Yehuda Afek afek@post.tau.ac.il Adam Morrison adamx@post.tau.ac.il School of Computer Science Tel Aviv University Guy Wertheim vgvertex@gmail.com
Time and Space Lower Bounds for Implementations Using k-cas
Time and Space Lower Bounds for Implementations Using k-cas Hagit Attiya Danny Hendler September 12, 2006 Abstract This paper presents lower bounds on the time- and space-complexity of implementations
Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors. Michel Raynal, Julien Stainer
Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors Michel Raynal, Julien Stainer Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors
Mutual Exclusion. 1 Formal problem definitions. Time notion CSE /17/2015. Outline of this lecture:
CSE 539 03/17/2015 Mutual Exclusion Lecture 15 Scribe: Son Dinh Outline of this lecture: 1. Formal problem definitions 2. Solution for 2 threads 3. Solution for n threads 4. Inherent costs of mutual exclusion
On the Importance of Synchronization Primitives with Low Consensus Numbers
On the Importance of Synchronization Primitives with Low Consensus Numbers ABSTRACT Pankaj Khanchandani ETH Zurich kpankaj@ethz.ch The consensus number of a synchronization primitive is the maximum number
Concurrent Objects. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Concurrent Objects Companion slides for The by Maurice Herlihy & Nir Shavit Concurrent Computation memory object object 2 Objectivism What is a concurrent object? How do we describe one? How do we implement
Multi-Core Computing with Transactional Memory. Johannes Schneider and Prof. Roger Wattenhofer
Multi-Core Computing with Transactional Memory Johannes Schneider and Prof. Roger Wattenhofer 1 Overview Introduction Difficulties with parallel (multi-core) programming A (partial) solution: Transactional
Lecture 18: Reliable Storage
CS 422/522 Design & Implementation of Operating Systems Lecture 18: Reliable Storage Zhong Shao Dept. of Computer Science Yale University Acknowledgement: some slides are taken from previous versions of
Cache-Aware Lock-Free Queues for Multiple Producers/Consumers and Weak Memory Consistency
Cache-Aware Lock-Free Queues for Multiple Producers/Consumers and Weak Memory Consistency Anders Gidenstam Håkan Sundell Philippas Tsigas School of business and informatics University of Borås Distributed
Background. 20: Distributed File Systems. DFS Structure. Naming and Transparency. Naming Structures. Naming Schemes Three Main Approaches
Background 20: Distributed File Systems Last Modified: 12/4/2002 9:26:20 PM Distributed file system (DFS) a distributed implementation of the classical time-sharing model of a file system, where multiple
Synchronization Principles II
CSC 256/456: Operating Systems Synchronization Principles II John Criswell University of Rochester 1 Synchronization Issues Race conditions and the need for synchronization Critical Section Problem Mutual
Anonymous and Fault-Tolerant Shared-Memory Computing
Distributed Computing manuscript No. (will be inserted by the editor) Rachid Guerraoui Eric Ruppert Anonymous and Fault-Tolerant Shared-Memory Computing the date of receipt and acceptance should be inserted
Distributed Synchronization. EECS 591 Farnam Jahanian University of Michigan
Distributed Synchronization EECS 591 Farnam Jahanian University of Michigan Reading List Tanenbaum Chapter 5.1, 5.4 and 5.5 Clock Synchronization Distributed Election Mutual Exclusion Clock Synchronization
Building Efficient Concurrent Graph Object through Composition of List-based Set
Building Efficient Concurrent Graph Object through Composition of List-based Set Sathya Peri Muktikanta Sa Nandini Singhal Department of Computer Science & Engineering Indian Institute of Technology Hyderabad
Distributed Data Management Transactions
Felix Naumann F-2.03/F-2.04, Campus II Hasso Plattner Institut must ensure that interactions succeed consistently An OLTP Topic Motivation Most database interactions consist of multiple, coherent operations
AST: scalable synchronization Supervisors guide 2002
AST: scalable synchronization Supervisors guide 00 tim.harris@cl.cam.ac.uk These are some notes about the topics that I intended the questions to draw on. Do let me know if you find the questions unclear
A Non-Blocking Concurrent Queue Algorithm
A Non-Blocking Concurrent Queue Algorithm Bruno Didot bruno.didot@epfl.ch June 2012 Abstract This report presents a new non-blocking concurrent FIFO queue backed by an unrolled linked list. Enqueue and
Solo-Valency and the Cost of Coordination
Solo-Valency and the Cost of Coordination Danny Hendler Nir Shavit November 21, 2007 Abstract This paper introduces solo-valency, a variation on the valency proof technique originated by Fischer, Lynch,
G52CON: Concepts of Concurrency
G52CON: Concepts of Concurrency Lecture 8 Semaphores II Natasha Alechina School of Computer Science nza@cs.nott.ac.uk Outline of this lecture problem solving with semaphores solving Producer-Consumer problems
PROCESS SYNCHRONIZATION
PROCESS SYNCHRONIZATION Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization
PRIMARY-BACKUP REPLICATION
PRIMARY-BACKUP REPLICATION Primary Backup George Porter Nov 14, 2018 ATTRIBUTION These slides are released under an Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0) Creative Commons
Shared Objects. Shared Objects
Shared Objects Shared Objects Invoked operations have a non-zero duration Invocations can overlap Useful for: modeling distributed shared memory Objects can be combined together to implement higher level
Temporal Logic of Actions (TLA) (a brief introduction) Shmuel Katz Computer Science Department The Technion
Temporal Logic of Actions (TLA) (a brief introduction) Shmuel Katz Computer Science Department The Technion CS236368 Formal Specifications Lecture-- TLA 1 Basic Idea Combine transitions with temporal logic
Help when needed, but no more: Efficient Read/Write Partial Snapshot
Help when needed, but no more: Efficient Read/Write Partial Snapshot Damien Imbs, Michel Raynal To cite this version: Damien Imbs, Michel Raynal. Help when needed, but no more: Efficient Read/Write Partial
CS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017
CS 471 Operating Systems Yue Cheng George Mason University Fall 2017 1 Review: Sync Terminology Worksheet 2 Review: Semaphores 3 Semaphores o Motivation: Avoid busy waiting by blocking a process execution
Unit 6: Indeterminate Computation
Unit 6: Indeterminate Computation Martha A. Kim October 6, 2013 Introduction Until now, we have considered parallelizations of sequential programs. The parallelizations were deemed safe if the parallel
Linearizability of Persistent Memory Objects
Linearizability of Persistent Memory Objects Michael L. Scott Joint work with Joseph Izraelevitz & Hammurabi Mendes www.cs.rochester.edu/research/synchronization/ Workshop on the Theory of Transactional
PROVING THINGS ABOUT PROGRAMS
PROVING THINGS ABOUT CONCURRENT PROGRAMS Lecture 23 CS2110 Fall 2010 Overview 2 Last time we looked at techniques for proving things about recursive algorithms We saw that in general, recursion matches
Concurrent Preliminaries
Concurrent Preliminaries Sagi Katorza Tel Aviv University 09/12/2014 1 Outline Hardware infrastructure Hardware primitives Mutual exclusion Work sharing and termination detection Concurrent data structures
DISTRIBUTED COMPUTING COLUMN. Stefan Schmid TU Berlin & T-Labs, Germany
DISTRIBUTED COMPUTING COLUMN Stefan Schmid TU Berlin & T-Labs, Germany stefan.schmid@tu-berlin.de 1 The Renaming Problem: Recent Developments and Open Questions Dan Alistarh (Microsoft Research) 1 Introduction
Reuse, don t Recycle: Transforming Lock-free Algorithms that Throw Away Descriptors
Reuse, don t Recycle: Transforming Lock-free Algorithms that Throw Away Descriptors Maya Arbel-Raviv and Trevor Brown Technion, Computer Science Department, Haifa, Israel mayaarl@cs.technion.ac.il, me@tbrown.pro
Lower bounds for Transactional memory
Lower bounds for Transactional memory Srivatsan Ravi Purdue University Abstract Transactional memory allows the user to declare sequences of instructions as speculative transactions that can either commit
Consistency. CS 475, Spring 2018 Concurrent & Distributed Systems
Consistency CS 475, Spring 2018 Concurrent & Distributed Systems Review: 2PC, Timeouts when Coordinator crashes What if the bank doesn t hear back from coordinator? If bank voted no, it s OK to abort If
On the Time and Space Complexity of ABA Prevention and Detection
On the Time and Space Complexity of ABA Prevention and Detection arxiv:1507.02722v1 [cs.dc] 9 Jul 2015 Zahra Aghazadeh University of Calgary Philipp Woelfel University of Calgary We investigate the time
NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY. Tim Harris, 31 October 2012
NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY Tim Harris, 31 October 2012 Lecture 6 Linearizability Lock-free progress properties Queues Reducing contention Explicit memory management Linearizability
Shared Memory Synchronization
Shared Memory Synchronization Gadi Taubenfeld The Interdisciplinary Center, P.O.Box 167, Herzliya 46150, Israel, tgadi@idc.ac.il, http://www.faculty.idc.ac.il/gadi/ September 1, 2008 Abstract. Synchronization
TWO-PHASE COMMIT ATTRIBUTION 5/11/2018. George Porter May 9 and 11, 2018
TWO-PHASE COMMIT George Porter May 9 and 11, 2018 ATTRIBUTION These slides are released under an Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0) Creative Commons license These slides
6.852: Distributed Algorithms Fall, Class 15
6.852: Distributed Algorithms Fall, 2009 Class 15 Today s plan z z z z z Pragmatic issues for shared-memory multiprocessors Practical mutual exclusion algorithms Test-and-set locks Ticket locks Queue locks
Concurrent Systems. XIII. Progress Guarantee. Wolfgang Schröder-Preikschat. Selbststudium. Nebenläufige Systeme
Concurrent Systems Nebenläufige Systeme XIII. Progress Guarantee Wolfgang Schröder-Preikschat Selbststudium Agenda In a Nutshell wosch CS ( Selbststudium ) In a Nutshell 2 Outline In a Nutshell wosch CS
Concurrent specifications beyond linearizability
Concurrent specifications beyond linearizability Éric Goubault Jérémy Ledent Samuel Mimram École Polytechnique, France OPODIS 2018, Hong Kong December 19, 2018 1 / 14 Objects Processes communicate through
Wait-Free Multi-Word Compare-And-Swap using Greedy Helping and Grabbing
Wait-Free Multi-Word Compare-And-Swap using Greedy Helping and Grabbing H. Sundell 1 1 School of Business and Informatics, University of Borås, Borås, Sweden Abstract We present a new algorithm for implementing
Lecture 7: Mutual Exclusion 2/16/12. slides adapted from The Art of Multiprocessor Programming, Herlihy and Shavit
Principles of Concurrency and Parallelism Lecture 7: Mutual Exclusion 2/16/12 slides adapted from The Art of Multiprocessor Programming, Herlihy and Shavit Time Absolute, true and mathematical time, of
How Live Can a Transactional Memory Be?
How Live Can a Transactional Memory Be? Rachid Guerraoui Michał Kapałka February 18, 2009 Abstract This paper asks how much liveness a transactional memory (TM) implementation can guarantee. We first devise
The Space Complexity of Unbounded Timestamps
The Space Complexity of Unbounded Timestamps Faith Ellen 1, Panagiota Fatourou 2, and Eric Ruppert 3 1 University of Toronto, Canada 2 University of Ioannina, Greece 3 York University, Canada Abstract.
Lock-free Serializable Transactions
Lock-free Serializable Transactions Jeff Napper jmn@cs.utexas.edu Lorenzo Alvisi lorenzo@cs.utexas.edu Laboratory for Advanced Systems Research Department of Computer Science The University of Texas at
Synchronization. Chapter 5
Synchronization Chapter 5 Clock Synchronization In a centralized system time is unambiguous. (each computer has its own clock) In a distributed system achieving agreement on time is not trivial. (it is
CONCURRENCY CONTROL, TRANSACTIONS, LOCKING, AND RECOVERY
CONCURRENCY CONTROL, TRANSACTIONS, LOCKING, AND RECOVERY George Porter May 18, 2018 ATTRIBUTION These slides are released under an Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0) Creative
Synchronization Part 2. REK s adaptation of Claypool s adaptation oftanenbaum s Distributed Systems Chapter 5 and Silberschatz Chapter 17
Synchronization Part 2 REK s adaptation of Claypool s adaptation oftanenbaum s Distributed Systems Chapter 5 and Silberschatz Chapter 17 1 Outline Part 2! Clock Synchronization! Clock Synchronization Algorithms!
Causal Consistency and Two-Phase Commit
Causal Consistency and Two-Phase Commit CS 240: Computing Systems and Concurrency Lecture 16 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. Consistency
6.852: Distributed Algorithms Fall, Class 20
6.852: Distributed Algorithms Fall, 2009 Class 20 Today s plan z z z Transactional Memory Reading: Herlihy-Shavit, Chapter 18 Guerraoui, Kapalka, Chapters 1-4 Next: z z z Asynchronous networks vs asynchronous
Message-Efficient Uniform Timed Reliable Broadcast Yu Ma and Scott D. Stoller 21 September Introduction In distributed database systems,
Message-Efficient Uniform Timed Reliable Broadcast Yu Ma and Scott D. Stoller 21 September 1998 1. Introduction In distributed database systems, atomic commitment protocols ensure that transactions leave
Synchronization (contd.)
Outline Synchronization (contd.) http://net.pku.edu.cn/~course/cs501/2008 Hongfei Yan School of EECS, Peking University 3/17/2008 Mutual Exclusion Permission-based Token-based Election Algorithms The Bully
Local-spin Abortable Mutual Exclusion. Hyonho Lee
Local-spin Abortable Mutual Exclusion by Hyonho Lee A thesis submitted in conformity with the requirements for the degree of Doctor of Philosophy Graduate Department of Computer Science University of Toronto
Computer Engineering II Solution to Exercise Sheet Chapter 10
Distributed Computing FS 2017 Prof. R. Wattenhofer Computer Engineering II Solution to Exercise Sheet Chapter 10 Quiz 1 Quiz a) The AtomicBoolean utilizes an atomic version of getandset() implemented in
Self Stabilization. CS553 Distributed Algorithms Prof. Ajay Kshemkalyani. by Islam Ismailov & Mohamed M. Ali
Self Stabilization CS553 Distributed Algorithms Prof. Ajay Kshemkalyani by Islam Ismailov & Mohamed M. Ali Introduction There is a possibility for a distributed system to go into an illegitimate state,
Introduction to programming with semaphores Fri 1 Sep 2017
Introduction to programming with semaphores Fri 1 Sep 2017 K. V. S. Prasad Dept of Computer Science Chalmers University Lecture 2 of TDA384/DIT301, August October2017 Assignments? How s it going with the
[module 2.2] MODELING CONCURRENT PROGRAM EXECUTION
![[module 2.2] MODELING CONCURRENT PROGRAM EXECUTION](/thumbs/87/95993460.jpg "[module 2.2] MODELING CONCURRENT PROGRAM EXECUTION")
v1.0 20130407 Programmazione Avanzata e Paradigmi Ingegneria e Scienze Informatiche - UNIBO a.a 2013/2014 Lecturer: Alessandro Ricci [module 2.2] MODELING CONCURRENT PROGRAM EXECUTION 1 SUMMARY Making
Learning Outcomes. Concurrency and Synchronisation. Textbook. Concurrency Example. Inter- Thread and Process Communication. Sections & 2.
Learning Outcomes Concurrency and Synchronisation Understand concurrency is an issue in operating systems and multithreaded applications Know the concept of a critical region. Understand how mutual exclusion
Multiple-Writer Distributed Memory
Multiple-Writer Distributed Memory The Sequential Consistency Memory Model sequential processors issue memory ops in program order P1 P2 P3 Easily implemented with shared bus. switch randomly set after
Recoverable FCFS Mutual Exclusion with Wait-Free Recovery
Recoverable FCFS Mutual Exclusion with Wait-Free Recovery Prasad Jayanti 1 and Anup Joshi 2 1 6211 Sudikoff Lab for Computer Science, Dartmouth College, Hanover, NH, USA prasad@cs.dartmouth.edu 2 6211
Chapter 16: Distributed Synchronization
Chapter 16: Distributed Synchronization Chapter 16 Distributed Synchronization Event Ordering Mutual Exclusion Atomicity Concurrency Control Deadlock Handling Election Algorithms Reaching Agreement 18.2
Generic Proofs of Consensus Numbers for Abstract Data Types
Generic Proofs of Consensus Numbers for Abstract Data Types Edward Talmage and Jennifer Welch Parasol Laboratory, Texas A&M University College Station, Texas, USA etalmage@tamu.edu, welch@cse.tamu.edu
Concurrency and Synchronisation
Concurrency and Synchronisation 1 Sections 2.3 & 2.4 Textbook 2 Making Single-Threaded Code Multithreaded Conflicts between threads over the use of a global variable 3 Inter- Thread and Process Communication
Shared Memory. Chapter Model
Chapter 5 Shared Memory In distributed computing, various different models exist. So far, the focus of the course was on loosely-coupled distributed systems such as the Internet, where nodes asynchronously
Mutual Exclusion: Classical Algorithms for Locks
Mutual Exclusion: Classical Algorithms for Locks John Mellor-Crummey Department of Computer Science Rice University johnmc@cs.rice.edu COMP 422 Lecture 18 21 March 2006 Motivation Ensure that a block of
Transactional Memory: Architectural Support for Lock-Free Data Structures Maurice Herlihy and J. Eliot B. Moss ISCA 93
Transactional Memory: Architectural Support for Lock-Free Data Structures Maurice Herlihy and J. Eliot B. Moss ISCA 93 What are lock-free data structures A shared data structure is lock-free if its operations
Concurrency and Synchronisation
Concurrency and Synchronisation 1 Learning Outcomes Understand concurrency is an issue in operating systems and multithreaded applications Know the concept of a critical region. Understand how mutual exclusion
Introduction. Coherency vs Consistency. Lec-11. Multi-Threading Concepts: Coherency, Consistency, and Synchronization
Lec-11 Multi-Threading Concepts: Coherency, Consistency, and Synchronization Coherency vs Consistency Memory coherency and consistency are major concerns in the design of shared-memory systems. Consistency
Operating Systems. Thread Synchronization Primitives. Thomas Ropars.
1 Operating Systems Thread Synchronization Primitives Thomas Ropars thomas.ropars@univ-grenoble-alpes.fr 2017 2 Agenda Week 42/43: Synchronization primitives Week 44: Vacation Week 45: Synchronization
Leader Election in Rings
Leader Election Arvind Krishnamurthy Fall 2003 Leader Election in Rings Under different models: Synchronous vs. asynchronous Anonymous vs. non-anonymous (knowledge of unique id) Knowledge of n (non-uniform)
Distributed Computing. CS439: Principles of Computer Systems November 19, 2018
Distributed Computing CS439: Principles of Computer Systems November 19, 2018 Bringing It All Together We ve been studying how an OS manages a single CPU system As part of that, it will communicate with
Ownership of a queue for practical lock-free scheduling
Ownership of a queue for practical lock-free scheduling Lincoln Quirk May 4, 2008 Abstract We consider the problem of scheduling tasks in a multiprocessor. Tasks cannot always be scheduled independently
Chapter 5 Concurrency: Mutual Exclusion and Synchronization
Operating Systems: Internals and Design Principles Chapter 5 Concurrency: Mutual Exclusion and Synchronization Seventh Edition By William Stallings Designing correct routines for controlling concurrent
Chapter 18: Distributed
Chapter 18: Distributed Synchronization, Silberschatz, Galvin and Gagne 2009 Chapter 18: Distributed Synchronization Event Ordering Mutual Exclusion Atomicity Concurrency Control Deadlock Handling Election