Linked Lists: Locking, Lock- Free, and Beyond. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
|
|
|
- Julie Rose
- 5 years ago
- Views:
Transcription
1 Linked Lists: Locking, Lock- Free, and Beyond Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
2 Coarse-Grained Synchronization Each method locks the object Avoid contention using queue locks Easy to reason about In simple cases Standard Java model Synchronized blocks and methods So, are we done? Art of Multiprocessor Programming 2
3 Coarse-Grained Synchronization Sequential bottleneck Threads stand in line Adding more threads Does not improve throughput Struggle to keep it from getting worse So why even use a multiprocessor? Well, some apps inherently parallel Art of Multiprocessor Programming 3
4 First: Fine-Grained Synchronization Instead of using a single lock.. Split object into Independently-synchronized components Methods conflict when they access The same component At the same time Art of Multiprocessor Programming 4
5 Set Interface Unordered collection of items No duplicates Methods add(x) put x in set remove(x) take x out of set contains(x) tests if x in set Art of Multiprocessor Programming 5
6 List-Based Sets public interface Set<T> { public boolean add(t x); public boolean remove(t x); public boolean contains(t x); } Art of Multiprocessor Programming 6
7 List-Based Sets public interface Set<T> { public boolean add(t x); public boolean remove(t x); public boolean contains(t x); } Add item to set Art of Multiprocessor Programming 7
8 List-Based Sets public interface Set<T> { public boolean add(t x); public boolean remove(t x); public boolean contains(tt x); } Remove item from set Art of Multiprocessor Programming 8
9 List-Based Sets public interface Set<T> { public boolean add(t x); public boolean remove(t x); public boolean contains(t x); } Is item in set? Art of Multiprocessor Programming 9
10 List Node public class Node { public T item; public int key; public Node next; } Art of Multiprocessor Programming 10
11 List Node public class Node { public T item; public int key; public Node next; } item of interest Art of Multiprocessor Programming 11
12 List Node public class Node { public T item; public int key; public Node next; } Usually hash code Art of Multiprocessor Programming 12
13 List Node public class Node { public T item; public int key; public Node next; } Reference to next node Art of Multiprocessor Programming 13
14 The List-Based Set - a b c + Sorted with Sentinel nodes (min & max possible keys) Art of Multiprocessor Programming 14
15 Reasoning about Concurrent Objects Invariant Property that always holds Established because True when object is created Truth preserved by each method Each step of each method Art of Multiprocessor Programming 15
16 Specifically Invariants preserved by add() remove() contains() Most steps are trivial Usually one step tricky Often linearization point Art of Multiprocessor Programming 16
17 Interference Invariants make sense only if methods considered are the only modifiers Language encapsulation helps List nodes not visible outside class Art of Multiprocessor Programming 17
18 Interference Freedom from interference needed even for removed nodes Some algorithms traverse removed nodes Careful with malloc() & free()! Garbage-collection helps here Art of Multiprocessor Programming 18
19 Abstract Data Types Concrete representation a b Abstract Type {a, b} Art of Multiprocessor Programming 19
20 Abstract Data Types Meaning of rep given by abstraction map S( a b ) = {a,b} Art of Multiprocessor Programming 20
21 Rep Invariant Which concrete values meaningful? Sorted? Duplicates? Rep invariant Characterizes legal concrete reps Preserved by methods Relied on by methods Art of Multiprocessor Programming 21
22 Blame Game Rep invariant is a contract Suppose add() leaves behind 2 copies of x remove() removes only 1 Which one is incorrect? Art of Multiprocessor Programming 22
23 Blame Game Suppose add() leaves behind 2 copies of x remove() removes only 1 Which one is incorrect? If rep invariant says no duplicates add() is incorrect Otherwise remove() is incorrect Art of Multiprocessor Programming 23
24 Rep Invariant (partly) Sentinel nodes tail reachable from head Sorted No duplicates Art of Multiprocessor Programming 24
25 Abstraction Map S(head) = { x there exists a such that } a reachable from head and a.item = x Art of Multiprocessor Programming 25
26 Sequential List Based Set Add() a c d Remove() a b c Art of Multiprocessor Programming 26
27 Sequential List Based Set Add() a c d Remove() b a b c Art of Multiprocessor Programming 27
28 Course Grained Locking a b d Art of Multiprocessor Programming 28
29 Course Grained Locking a b d c Art of Multiprocessor Programming 29
30 Course Grained Locking a b d honk! honk! c Simple but hotspot + bottleneck Art of Multiprocessor Programming 30
31 Coarse-Grained Locking Easy, same as synchronized methods One lock to rule them all Simple, clearly correct Deserves respect! Works poorly with contention Queue locks help But bottleneck still an issue Art of Multiprocessor Programming 31
32 Fine-grained Locking Requires careful thought Do not meddle in the affairs of wizards, for they are subtle and quick to anger Split object into pieces Each piece has own lock Methods that work on disjoint pieces need not exclude each other Art of Multiprocessor Programming 32
33 Hand-over-Hand locking a b c Art of Multiprocessor Programming 33
34 Hand-over-Hand locking a b c Art of Multiprocessor Programming 34
35 Hand-over-Hand locking a b c Art of Multiprocessor Programming 35
36 Hand-over-Hand locking a b c Art of Multiprocessor Programming 36
37 Hand-over-Hand locking a b c Art of Multiprocessor Programming 37
38 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 38
39 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 39
40 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 40
41 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 41
42 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 42
43 Removing a Node a c d remove(b) Why do we need to always hold 2 locks? Art of Multiprocessor Programming 43
44 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 44
45 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 45
46 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 46
47 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 47
48 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 48
49 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 49
50 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 50
51 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 51
52 Uh, Oh a c d remove(b) remove(c) Art of Multiprocessor Programming 52
53 Uh, Oh Bad news, C not removed a c d remove(b) remove(c) Art of Multiprocessor Programming 53
54 Problem To delete node c Swing node b s next field to d a b c Problem is, Someone deleting b concurrently could direct a pointer a b c to c Art of Multiprocessor Programming 54
55 Insight If a node is locked No one can delete node s successor If a thread locks Node to be deleted And its predecessor Then it works Art of Multiprocessor Programming 55
56 Hand-Over-Hand Again a b c d remove(b) Art of Multiprocessor Programming 56
57 Hand-Over-Hand Again a b c d remove(b) Art of Multiprocessor Programming 57
58 Hand-Over-Hand Again a b c d remove(b) Art of Multiprocessor Programming 58
59 Hand-Over-Hand Again a b c d remove(b) Found it! Art of Multiprocessor Programming 59
60 Hand-Over-Hand Again a b c d remove(b) Found it! Art of Multiprocessor Programming 60
61 Hand-Over-Hand Again a c d remove(b) Art of Multiprocessor Programming 61
62 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 62
63 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 63
64 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 64
65 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 65
66 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 66
67 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 67
68 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 68
69 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 69
70 Removing a Node a b c d Must acquire Lock of b remove(c) Art of Multiprocessor Programming 70
71 Removing a Node a b c d Cannot acquire lock of b remove(c) Art of Multiprocessor Programming 71
72 Removing a Node a b c d Wait! remove(c) Art of Multiprocessor Programming 72
73 Removing a Node a b d Proceed to remove(b) Art of Multiprocessor Programming 73
74 Removing a Node a b d remove(b) Art of Multiprocessor Programming 74
75 Removing a Node a b d remove(b) Art of Multiprocessor Programming 75
76 Removing a Node a d remove(b) Art of Multiprocessor Programming 76
77 Removing a Node a d Art of Multiprocessor Programming 77
78 Remove method public boolean remove(item item) { int key = item.hashcode(); Node pred, curr; try { } finally { curr.unlock(); pred.unlock(); }} Art of Multiprocessor Programming 78
79 Remove method public boolean remove(item item) { int key = item.hashcode(); Node pred, curr; try { } finally { curr.unlock(); pred.unlock(); }} Key used to order node Art of Multiprocessor Programming 79
80 Remove method public boolean remove(item item) { int key = item.hashcode(); Node pred, curr; try { } finally { currnode.unlock(); prednode.unlock(); }} Predecessor and current nodes Art of Multiprocessor Programming 80
81 Remove method public boolean remove(item item) { int key = item.hashcode(); Node pred, curr; try { } finally { curr.unlock(); pred.unlock(); }} Make sure locks released Art of Multiprocessor Programming 81
82 Remove method public boolean remove(item item) { int key = item.hashcode(); Node pred, curr; try { } finally { curr.unlock(); pred.unlock(); }} Everything else Art of Multiprocessor Programming 82
83 Remove method try { pred = this.head; pred.lock(); curr = pred.next; curr.lock(); } finally { } Art of Multiprocessor Programming 83
84 Remove method lock pred == head try { pred = this.head; pred.lock(); curr = pred.next; curr.lock(); } finally { } Art of Multiprocessor Programming 84
85 Remove method try { pred = this.head; pred.lock(); curr = pred.next; curr.lock(); } finally { } Lock current Art of Multiprocessor Programming 85
86 Remove method try { pred = this.head; pred.lock(); curr = pred.next; curr.lock(); } finally { } Traversing list Art of Multiprocessor Programming 86
87 Remove: searching while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Art of Multiprocessor Programming 87
88 Remove: searching while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } Search key range pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Art of Multiprocessor Programming 88
89 Remove: searching while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; At start of each loop: curr and pred locked Art of Multiprocessor Programming 89
90 Remove: searching while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; If item found, remove node Art of Multiprocessor Programming 90
91 Remove: searching while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; If node found, remove it Art of Multiprocessor Programming 91
92 Remove: searching Unlock predecessor while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Art of Multiprocessor Programming 92
93 Remove: searching Only one node locked! while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Art of Multiprocessor Programming 93
94 Remove: searching while (curr.key <= key) { demote current if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Art of Multiprocessor Programming 94
95 Remove: searching while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = currnode; curr = curr.next; curr.lock(); } return false; Find and lock new current Art of Multiprocessor Programming 95
96 Remove: searching while (curr.key <= key) { Lock if (item invariant == curr.item) restored { pred.next = curr.next; return true; } pred.unlock(); pred = currnode; curr = curr.next; curr.lock(); } return false; Art of Multiprocessor Programming 96
97 Remove: searching while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Otherwise, not present Art of Multiprocessor Programming 97
98 Why does this work? To remove node e Must lock e Must lock e s predecessor Therefore, if you lock a node It can t be removed And neither can its successor Art of Multiprocessor Programming 98
99 Why remove() is linearizable while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; pred reachable from head curr is pred.next So curr.item is in the set Art of Multiprocessor Programming 99
100 Why remove() is linearizable while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Linearization point if item is present Art of Multiprocessor Programming 100
101 Why remove() is linearizable while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Node locked, so no other thread can remove it. Art of Multiprocessor Programming 101
102 Why remove() is linearizable while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Item not present Art of Multiprocessor Programming 102
103 Why remove() is linearizable while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; pred reachable from head curr.lock(); curr is pred.next } pred.key < key return false; key < curr.key Art of Multiprocessor Programming 103
104 Why remove() is linearizable while (curr.key <= key) { if (item == curr.item) { pred.next = curr.next; return true; } pred.unlock(); pred = curr; curr = curr.next; curr.lock(); } return false; Linearization point Art of Multiprocessor Programming 104
105 Adding Nodes To add node e Must lock predecessor Must lock successor Neither can be deleted (Is successor lock actually required?) Art of Multiprocessor Programming 105
106 Same Abstraction Map S(head) = { x there exists a such that } a reachable from head and a.item = x Art of Multiprocessor Programming 106
107 Rep Invariant Easy to check that tail always reachable from head Nodes sorted, no duplicates Art of Multiprocessor Programming 107
108 Drawbacks Better than coarse-grained lock Threads can traverse in parallel Still not ideal Long chain of acquire/release Inefficient Art of Multiprocessor Programming 108
109 This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. You are free: to Share to copy, distribute and transmit the work to Remix to adapt the work Under the following conditions: Attribution. You must attribute the work to The Art of Multiprocessor Programming (but not in any way that suggests that the authors endorse you or your use of the work). Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to Any of the above conditions can be waived if you get permission from the copyright holder. Nothing in this license impairs or restricts the author's moral rights. Art of Multiprocessor Programming 109
Coarse-grained and fine-grained locking Niklas Fors
Coarse-grained and fine-grained locking Niklas Fors 2013-12-05 Slides borrowed from: http://cs.brown.edu/courses/cs176course_information.shtml Art of Multiprocessor Programming 1 Topics discussed Coarse-grained
Locking Granularity. CS 475, Spring 2019 Concurrent & Distributed Systems. With material from Herlihy & Shavit, Art of Multiprocessor Programming
Locking Granularity CS 475, Spring 2019 Concurrent & Distributed Systems With material from Herlihy & Shavit, Art of Multiprocessor Programming Discussion: HW1 Part 4 addtolist(key1, newvalue) Thread 1
Linked Lists: Locking, Lock-Free, and Beyond. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Linked Lists: Locking, Lock-Free, and Beyond Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Concurrent Objects Adding threads should not lower throughput Contention
Linked Lists: Locking, Lock- Free, and Beyond. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Linked Lists: Locking, Lock- Free, and Beyond Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Last Lecture: Spin-Locks CS. spin lock critical section Resets lock
Programming Paradigms for Concurrency Lecture 6 Synchronization of Concurrent Objects
Programming Paradigms for Concurrency Lecture 6 Synchronization of Concurrent Objects Based on companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Thomas
Last Lecture: Spin-Locks
Linked Lists: Locking, Lock- Free, and Beyond Last Lecture: Spin-Locks. spin lock CS critical section Resets lock upon exit Today: Concurrent Objects Adding threads should not lower throughput Contention
Introduction to Concurrency and Multicore Programming. Slides adapted from Art of Multicore Programming by Herlihy and Shavit
Introduction to Concurrency and Multicore Programming Slides adapted from Art of Multicore Programming by Herlihy and Shavit Overview Introduction Mutual Exclusion Linearizability Concurrent Data Structure
Concurrent Skip Lists. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Concurrent Skip Lists Companion slides for The by Maurice Herlihy & Nir Shavit Set Object Interface Collection of elements No duplicates Methods add() a new element remove() an element contains() if element
Concurrency. Part 2, Chapter 10. Roger Wattenhofer. ETH Zurich Distributed Computing
Concurrency Part 2, Chapter 10 Roger Wattenhofer ETH Zurich Distributed Computing www.disco.ethz.ch Overview Concurrent Linked List Fine-grained synchronization Optimistic synchronization Lazy synchronization
Concurrent Data Structures
Concurrent Data Structures Chapter 8 Roger Wattenhofer ETH Zurich Distributed Computing www.disco.ethz.ch Overview Concurrent Linked List Fine-grained synchronization Optimistic synchronization Lazy synchronization
The Art of Multiprocessor Programming Copyright 2007 Elsevier Inc. All rights reserved. October 3, 2007 DRAFT COPY
The Art of Multiprocessor Programming Copyright 2007 Elsevier Inc. All rights reserved Maurice Herlihy October 3, 2007 Nir Shavit 2 Contents 1 Introduction 13 1.1 Shared Objects and Synchronization..............
Linked Lists: The Role of Locking. Erez Petrank Technion
Linked Lists: The Role of Locking Erez Petrank Technion Why Data Structures? Concurrent Data Structures are building blocks Used as libraries Construction principles apply broadly This Lecture Designing
Coarse-Grained Synchronization
Coarse-Grained Synchronization Ogni metodo opera mediante un lock sull oggetto Code di attesa per operare sull oggetto Nozione di correttezza (linearizability) Modello astratto basato sulla nozione di
Introduction. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Introduction Companion slides for The by Maurice Herlihy & Nir Shavit Moore s Law Transistor count still rising Clock speed flattening sharply 2 Moore s Law (in practice) 3 Nearly Extinct: the Uniprocesor
Solution: a lock (a/k/a mutex) public: virtual void unlock() =0;
1 Solution: a lock (a/k/a mutex) class BasicLock { public: virtual void lock() =0; virtual void unlock() =0; ; 2 Using a lock class Counter { public: int get_and_inc() { lock_.lock(); int old = count_;
Locking. Part 2, Chapter 7. Roger Wattenhofer. ETH Zurich Distributed Computing
Locking Part 2, Chapter 7 Roger Wattenhofer ETH Zurich Distributed Computing www.disco.ethz.ch Overview Introduction Spin Locks Test-and-Set & Test-and-Test-and-Set Backoff lock Queue locks Concurrent
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
Spin Locks and Contention. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Real world concurrency Understanding hardware architecture What is contention How to
Concurrent Queues, Monitors, and the ABA problem. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Concurrent Queues, Monitors, and the ABA problem Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Queues Often used as buffers between producers and consumers
Hashing and Natural Parallism. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Hashing and Natural Parallism Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Sequential Closed Hash Map 0 1 2 3 16 9 buckets 2 Items h(k) = k mod 4 Art of Multiprocessor
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
Spin Locks and Contention
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified for Software1 students by Lior Wolf and Mati Shomrat Kinds of Architectures
Modern High-Performance Locking
Modern High-Performance Locking Nir Shavit Slides based in part on The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Locks (Mutual Exclusion) public interface Lock { public void lock();
Practice: Small Systems Part 2, Chapter 3
Practice: Small Systems Part 2, Chapter 3 Roger Wattenhofer Overview Introduction Spin Locks Test and Set & Test and Test and Set Backoff lock Queue locks Concurrent Linked List Fine grained synchronization
Shared-Memory Computability
Shared-Memory Computability 10011 Universal Object Wait-free/Lock-free computable = Threads with methods that solve n- consensus Art of Multiprocessor Programming Copyright Herlihy- Shavit 2007 93 GetAndSet
Spin Locks and Contention. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Focus so far: Correctness and Progress Models Accurate (we never lied to you) But idealized
Non-Blocking Synchronization
Herlihy Ch 9. Linked Lists: The Role of Locking Non-Blocking Synchronization BJÖRN A. JOHNSSON Overview? So far: Coarse- and fine-grained synchronization Optimistic synchronization Lazy synchronization
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
Mutual Exclusion. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Mutual Exclusion Companion slides for The by Maurice Herlihy & Nir Shavit Mutual Exclusion Today we will try to formalize our understanding of mutual exclusion We will also use the opportunity to show
Parallel linked lists
Parallel linked lists Lecture 10 of TDA384/DIT391 (Principles of Conent Programming) Carlo A. Furia Chalmers University of Technology University of Gothenburg SP3 2017/2018 Today s menu The burden of locking
Integrating Transactionally Boosted Data Structures with STM Frameworks: A Case Study on Set
Integrating Transactionally Boosted Data Structures with STM Frameworks: A Case Study on Set Ahmed Hassan Roberto Palmieri Binoy Ravindran Virginia Tech hassan84@vt.edu robertop@vt.edu binoy@vt.edu Abstract
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
Concurrent Data Structures Concurrent Algorithms 2016
Concurrent Data Structures Concurrent Algorithms 2016 Tudor David (based on slides by Vasileios Trigonakis) Tudor David 11.2016 1 Data Structures (DSs) Constructs for efficiently storing and retrieving
Spin Locks and Contention. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for The Programming by Maurice Herlihy & Nir Shavit Focus so far: Correctness Models Accurate (we never lied to you) But idealized (so we forgot to mention a
A simple correctness proof of the MCS contention-free lock. Theodore Johnson. Krishna Harathi. University of Florida. Abstract
A simple correctness proof of the MCS contention-free lock Theodore Johnson Krishna Harathi Computer and Information Sciences Department University of Florida Abstract Mellor-Crummey and Scott present
PERFORMANCE ANALYSIS AND OPTIMIZATION OF SKIP LISTS FOR MODERN MULTI-CORE ARCHITECTURES
PERFORMANCE ANALYSIS AND OPTIMIZATION OF SKIP LISTS FOR MODERN MULTI-CORE ARCHITECTURES Anish Athalye and Patrick Long Mentors: Austin Clements and Stephen Tu 3 rd annual MIT PRIMES Conference Sequential
Concurrent Queues and Stacks. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Concurrent Queues and Stacks Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit The Five-Fold Path Coarse-grained locking Fine-grained locking Optimistic synchronization
Spin Locks and Contention. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit MIMD Architectures memory Shared Bus Memory Contention Communication Contention Communication
Peterson s Algorithm
Peterson s Algorithm public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; } 24/03/10 Art of Multiprocessor Programming 1 Mutual
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
Sequen&al Consistency and Linearizability
Sequen&al Consistency and Linearizability (Or, Reasoning About Concurrent Objects) Acknowledgement: Slides par&ally adopted from the companion slides for the book "The Art of Mul&processor Programming"
A Concurrent Skip List Implementation with RTM and HLE
A Concurrent Skip List Implementation with RTM and HLE Fan Gao May 14, 2014 1 Background Semester Performed: Spring, 2014 Instructor: Maurice Herlihy The main idea of my project is to implement a skip
Programming Paradigms for Concurrency Lecture 2 - Mutual Exclusion
Programming Paradigms for Concurrency Lecture 2 - Mutual Exclusion Based on companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Thomas Wies New York University
Locks Chapter 4. Overview. Introduction Spin Locks. Queue locks. Roger Wattenhofer. Test-and-Set & Test-and-Test-and-Set Backoff lock
Locks Chapter 4 Roger Wattenhofer ETH Zurich Distributed Computing www.disco.ethz.ch Overview Introduction Spin Locks Test-and-Set & Test-and-Test-and-Set Backoff lock Queue locks 4/2 1 Introduction: From
Formal Verification of a Lazy Concurrent List-Based Set Algorithm
Formal Verification of a Lazy Concurrent List-Based Set Algorithm Robert Colvin 1, Lindsay Groves 2, Victor Luchangco 3, and Mark Moir 3 1 ARC Centre for Complex Systems, School of Information Technology
Spin Locks and Contention. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Focus so far: Correctness and Progress Models Accurate (we never lied to you) But idealized
A Simple Optimistic skip-list Algorithm
A Simple Optimistic skip-list Algorithm Maurice Herlihy Brown University & Sun Microsystems Laboratories Yossi Lev Brown University & Sun Microsystems Laboratories yosef.lev@sun.com Victor Luchangco Sun
Programming Paradigms for Concurrency Introduction
Programming Paradigms for Concurrency Introduction Based on companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Thomas Wies New York University Moore
Spin Locks and Contention. Companion slides for Chapter 7 The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for Chapter 7 The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Focus so far: Correctness and Progress Models Accurate (we never lied to you)
Introduction. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit. Art of Multiprocessor Programming
Introduction Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Art of Multiprocessor Programming Moore s Law Transistor count still rising Clock speed flattening
Whatever can go wrong will go wrong. attributed to Edward A. Murphy. Murphy was an optimist. authors of lock-free programs LOCK FREE KERNEL
Whatever can go wrong will go wrong. attributed to Edward A. Murphy Murphy was an optimist. authors of lock-free programs LOCK FREE KERNEL 251 Literature Maurice Herlihy and Nir Shavit. The Art of Multiprocessor
Overview of Lecture 4. Memory Models, Atomicity & Performance. Ben-Ari Concurrency Model. Dekker s Algorithm 4
Concurrent and Distributed Programming http://fmt.cs.utwente.nl/courses/cdp/ Overview of Lecture 4 2 Memory Models, tomicity & Performance HC 4 - Tuesday, 6 December 2011 http://fmt.cs.utwente.nl/~marieke/
Parallel Programming
Parallel Programming 9. Pipeline Parallelism Christoph von Praun praun@acm.org 09-1 (1) Parallel algorithm structure design space Organization by Data (1.1) Geometric Decomposition Organization by Tasks
What We'll Cover Today
Mutual Exclusion Acknowledgement: Slides adopted from the companion slides for the book "The Art of Mul>processor Programming" by Maurice Herlihy and Nir Shavit What We'll Cover Today Chapter 2 of: Digital
15 418/618 Project Final Report Concurrent Lock free BST
15 418/618 Project Final Report Concurrent Lock free BST Names: Swapnil Pimpale, Romit Kudtarkar AndrewID: spimpale, rkudtark 1.0 SUMMARY We implemented two concurrent binary search trees (BSTs): a fine
Lecture 21: Transactional Memory. Topics: consistency model recap, introduction to transactional memory
Lecture 21: Transactional Memory Topics: consistency model recap, introduction to transactional memory 1 Example Programs Initially, A = B = 0 P1 P2 A = 1 B = 1 if (B == 0) if (A == 0) critical section
Advance Operating Systems (CS202) Locks Discussion
Advance Operating Systems (CS202) Locks Discussion Threads Locks Spin Locks Array-based Locks MCS Locks Sequential Locks Road Map Threads Global variables and static objects are shared Stored in the static
Page 1. Challenges" Concurrency" CS162 Operating Systems and Systems Programming Lecture 4. Synchronization, Atomic operations, Locks"
CS162 Operating Systems and Systems Programming Lecture 4 Synchronization, Atomic operations, Locks" January 30, 2012 Anthony D Joseph and Ion Stoica http://insteecsberkeleyedu/~cs162 Space Shuttle Example"
Cornell University Computer Science 211 Second Preliminary Examination 18 April 2006
Cornell University Computer Science 211 Second Preliminary Examination 18 April 2006 There are 4 problems on this exam. It is 8 pages long, so make sure you have the whole exam. You will have 1 1 hours
CS510 Concurrent Systems. Jonathan Walpole
CS510 Concurrent Systems Jonathan Walpole Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms utline Background Non-Blocking Queue Algorithm Two Lock Concurrent Queue Algorithm
Introduction. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Introduction Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Moore s Law Transistor count still rising Clock speed flattening sharply Art of Multiprocessor Programming
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
COMP Parallel Computing. CC-NUMA (2) Memory Consistency
COMP 633 - Parallel Computing Lecture 11 September 26, 2017 Memory Consistency Reading Patterson & Hennesey, Computer Architecture (2 nd Ed.) secn 8.6 a condensed treatment of consistency models Coherence
Whatever can go wrong will go wrong. attributed to Edward A. Murphy. Murphy was an optimist. authors of lock-free programs 3.
Whatever can go wrong will go wrong. attributed to Edward A. Murphy Murphy was an optimist. authors of lock-free programs 3. LOCK FREE KERNEL 309 Literature Maurice Herlihy and Nir Shavit. The Art of Multiprocessor
Spin Locks and Contention Management
Chapter 7 Spin Locks and Contention Management 7.1 Introduction We now turn our attention to the performance of mutual exclusion protocols on realistic architectures. Any mutual exclusion protocol poses
Locking. Part 2, Chapter 11. Roger Wattenhofer. ETH Zurich Distributed Computing
Locking Part 2, Chapter 11 Roger Wattenhofer ETH Zurich Distributed Computing www.disco.ethz.ch Overview Introduction Spin Locks Test-and-Set & Test-and-Test-and-Set Backoff lock Queue locks 11/2 Introduction:
Design of Parallel and High-Performance Computing Fall 2015 Lecture: Locks and Lock-Free continued
Design of Parallel and High-Performance Computing Fall 2015 Lecture: Locks and Lock-Free continued Motivational video: https://www.youtube.com/watch?v=-7bpo1quxyw Instructor: Torsten Hoefler & Markus Püschel
Implementing Mutual Exclusion. Sarah Diesburg Operating Systems CS 3430
Implementing Mutual Exclusion Sarah Diesburg Operating Systems CS 3430 From the Previous Lecture The too much milk example shows that writing concurrent programs directly with load and store instructions
Lecture: Consistency Models, TM. Topics: consistency models, TM intro (Section 5.6)
Lecture: Consistency Models, TM Topics: consistency models, TM intro (Section 5.6) 1 Coherence Vs. Consistency Recall that coherence guarantees (i) that a write will eventually be seen by other processors,
Combining Techniques Application for Tree Search Structures
RAYMOND AND BEVERLY SACKLER FACULTY OF EXACT SCIENCES BLAVATNIK SCHOOL OF COMPUTER SCIENCE Combining Techniques Application for Tree Search Structures Thesis submitted in partial fulfillment of requirements
Concurrent Counting using Combining Tree
Final Project Report by Shang Wang, Taolun Chai and Xiaoming Jia Concurrent Counting using Combining Tree 1. Introduction Counting is one of the very basic and natural activities that computers do. However,
Futures, Scheduling, and Work Distribution. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Futures, Scheduling, and Work Distribution Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit How to write Parallel Apps? How to split a program into parallel parts
Parallel Programming
Parallel Programming 7. Data Parallelism Christoph von Praun praun@acm.org 07-1 (1) Parallel algorithm structure design space Organization by Data (1.1) Geometric Decomposition Organization by Tasks (1.3)
Lecture 9: Multiprocessor OSs & Synchronization. CSC 469H1F Fall 2006 Angela Demke Brown
Lecture 9: Multiprocessor OSs & Synchronization CSC 469H1F Fall 2006 Angela Demke Brown The Problem Coordinated management of shared resources Resources may be accessed by multiple threads Need to control
Lecture 21: Transactional Memory. Topics: Hardware TM basics, different implementations
Lecture 21: Transactional Memory Topics: Hardware TM basics, different implementations 1 Transactions New paradigm to simplify programming instead of lock-unlock, use transaction begin-end locks are blocking,
Scheduler Activations. CS 5204 Operating Systems 1
Scheduler Activations CS 5204 Operating Systems 1 Concurrent Processing How can concurrent processing activity be structured on a single processor? How can application-level information and system-level
Reagent Based Lock Free Concurrent Link List Spring 2012 Ancsa Hannak and Mitesh Jain April 28, 2012
Reagent Based Lock Free Concurrent Link List Spring 0 Ancsa Hannak and Mitesh Jain April 8, 0 Introduction The most commonly used implementation of synchronization is blocking algorithms. They utilize
Distributed Computing Group
Distributed Computing Group HS 2009 Prof. Dr. Roger Wattenhofer, Thomas Locher, Remo Meier, Benjamin Sigg Assigned: December 11, 2009 Discussion: none Distributed Systems Theory exercise 6 1 ALock2 Have
Experience with Model Checking Linearizability
Experience with Model Checking Linearizability Martin Vechev, Eran Yahav, and Greta Yorsh IBM T.J. Watson Research Center Non-blocking concurrent algorithms offer significant performance advantages, but
The Universality of Consensus
Chapter 6 The Universality of Consensus 6.1 Introduction In the previous chapter, we considered a simple technique for proving statements of the form there is no wait-free implementation of X by Y. We
Agenda. Lecture. Next discussion papers. Bottom-up motivation Shared memory primitives Shared memory synchronization Barriers and locks
Agenda Lecture Bottom-up motivation Shared memory primitives Shared memory synchronization Barriers and locks Next discussion papers Selecting Locking Primitives for Parallel Programming Selecting Locking
Optimistic Transactional Boosting
1 Optimistic ransactional Boosting Ahmed Hassan, Roberto Palmieri, Sebastiano Peluso, and Binoy Ravindran Abstract he last two decades witnessed the success of many efficient designs of concurrent data
Thread Synchronization: Foundations. Properties. Safety properties. Edsger s perspective. Nothing bad happens
Edsger s perspective Testing can only prove the presence of bugs Thread Synchronization: Foundations Properties Property: a predicate that is evaluated over a run of the program (a trace) every message
Goldibear and the 3 Locks. Programming With Locks Is Tricky. More Lock Madness. And To Make It Worse. Transactional Memory: The Big Idea
Programming With Locks s Tricky Multicore processors are the way of the foreseeable future thread-level parallelism anointed as parallelism model of choice Just one problem Writing lock-based multi-threaded
A Comparison of Relativistic and Reader-Writer Locking Approaches to Shared Data Access
A Comparison of Relativistic and Reader-Writer Locking Approaches to Shared Data Access Philip W. Howard, Josh Triplett, and Jonathan Walpole Portland State University Abstract. This paper explores the
A Skiplist-based Concurrent Priority Queue with Minimal Memory Contention
A Skiplist-based Concurrent Priority Queue with Minimal Memory Contention Jonatan Lindén and Bengt Jonsson Uppsala University, Sweden December 18, 2013 Jonatan Lindén 1 Contributions Motivation: Improve
Lecture: Consistency Models, TM
Lecture: Consistency Models, TM Topics: consistency models, TM intro (Section 5.6) No class on Monday (please watch TM videos) Wednesday: TM wrap-up, interconnection networks 1 Coherence Vs. Consistency
CS 310: Hash Table Collision Resolution
CS 310: Hash Table Collision Resolution Chris Kauffman Week 8-1 Logistics Reading Weiss Ch 20: Hash Table Weiss Ch 6.7-8: Maps/Sets Homework HW 1 Due Saturday Discuss HW 2 next week Questions? Schedule
6. Intermediate Representation!
6. Intermediate Representation! Prof. O. Nierstrasz! Thanks to Jens Palsberg and Tony Hosking for their kind permission to reuse and adapt the CS132 and CS502 lecture notes.! http://www.cs.ucla.edu/~palsberg/!
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
CS 310: Hash Table Collision Resolution Strategies
CS 310: Hash Table Collision Resolution Strategies Chris Kauffman Week 7-1 Logistics HW 2 Due Wednesday night Test Cases Final Questions for group discussion? Goals Today Midterm Exam Next Monday Review
Lecture 7: Transactional Memory Intro. Topics: introduction to transactional memory, lazy implementation
Lecture 7: Transactional Memory Intro Topics: introduction to transactional memory, lazy implementation 1 Transactions New paradigm to simplify programming instead of lock-unlock, use transaction begin-end
Design and Evaluation of Scalable Software
Design and Evaluation of Scalable Software Damian Dechev 1,2 1: University of Central Florida, CSE S3 Lab, http://cse.eecs.ucf.edu Orlando, FL 2: Sandia Labs, Livermore, CA Traditional Scaling Process
Parallel access to linked data structures
Parallel access to linked data structures [Solihin Ch. 5] Answer the questions below. Name some linked data structures. What operations can be performed on all of these structures? Why is it hard to parallelize
IN5050: Programming heterogeneous multi-core processors Thinking Parallel
IN5050: Programming heterogeneous multi-core processors Thinking Parallel 28/8-2018 Designing and Building Parallel Programs Ian Foster s framework proposal develop intuition as to what constitutes a good
Today: Synchronization. Recap: Synchronization
Today: Synchronization Synchronization Mutual exclusion Critical sections Example: Too Much Milk Locks Synchronization primitives are required to ensure that only one thread executes in a critical section
Story so far. Parallel Data Structures. Parallel data structure. Working smoothly with Galois iterators
Story so far Parallel Data Structures Wirth s motto Algorithm + Data structure = Program So far, we have studied parallelism in regular and irregular algorithms scheduling techniques for exploiting parallelism
Snapshots and Software Transactional Memory
Snapshots and Software Transactional Memory Christopher Cole Northrop Grumman Corporation chris.cole@ngc.com Maurice Herlihy Brown University Computer Science Department herlihy@cs.brown.edu. ABSTRACT
CMSC Computer Architecture Lecture 15: Memory Consistency and Synchronization. Prof. Yanjing Li University of Chicago
CMSC 22200 Computer Architecture Lecture 15: Memory Consistency and Synchronization Prof. Yanjing Li University of Chicago Administrative Stuff! Lab 5 (multi-core) " Basic requirements: out later today
Design of Parallel and High-Performance Computing Fall 2017 Lecture: Locks (contd.) and Lock-Free
Design of Parallel and High-Performance Computing Fall 2017 Lecture: Locks (contd.) and Lock-Free Motivational video: https://www.youtube.com/watch?v=jhapqipqquw Instructor: Torsten Hoefler & Markus Püschel