Today’s Agenda  Midterm: Nov 3 or 10  Finish Message Passing  Race Analysis Advanced Topics in Software Engineering 1.

Slides:



Advertisements
Similar presentations
1 Interprocess Communication 1. Ways of passing information 2. Guarded critical activities (e.g. updating shared data) 3. Proper sequencing in case of.
Advertisements

CS542 Topics in Distributed Systems Diganta Goswami.
Concurrency: Deadlock and Starvation Chapter 6. Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Virtual Time “Virtual Time and Global States of Distributed Systems” Friedmann Mattern, 1989 The Model: An asynchronous distributed system = a set of processes.
D u k e S y s t e m s Time, clocks, and consistency and the JMM Jeff Chase Duke University.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Process Synchronization Continued 7.2 The Critical-Section Problem.
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
Eraser: A Dynamic Data Race Detector for Multithreaded Programs STEFAN SAVAGE, MICHAEL BURROWS, GREG NELSON, PATRICK SOBALVARRO and THOMAS ANDERSON.
Atomicity in Multi-Threaded Programs Prachi Tiwari University of California, Santa Cruz CMPS 203 Programming Languages, Fall 2004.
/ PSWLAB Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs By Cormac Flanagan, Stephen N. Freund 24 th April, 2008 Hong,Shin.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
CS533 Concepts of Operating Systems Class 3 Data Races and the Case Against Threads.
Ordering and Consistent Cuts Presented By Biswanath Panda.
Deadlocks. 2 System Model There are non-shared computer resources –Maybe more than one instance –Printers, Semaphores, Tape drives, CPU Processes need.
Concurrency CS 510: Programming Languages David Walker.
Concurrency: Mutual Exclusion, Synchronization, Deadlock, and Starvation in Representative Operating Systems.
Chapter 2.3 : Interprocess Communication
CS533 Concepts of Operating Systems Class 3 Monitors.
/ PSWLAB Eraser: A Dynamic Data Race Detector for Multithreaded Programs By Stefan Savage et al 5 th Mar 2008 presented by Hong,Shin Eraser:
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Mutual Exclusion Steve Ko Computer Sciences and Engineering University at Buffalo.
Object Oriented Analysis & Design SDL Threads. Contents 2  Processes  Thread Concepts  Creating threads  Critical sections  Synchronizing threads.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Mutual Exclusion Steve Ko Computer Sciences and Engineering University at Buffalo.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Introduction to Concurrency.
Operating Systems Distributed Coordination. Topics –Event Ordering –Mutual Exclusion –Atomicity –Concurrency Control Topics –Event Ordering –Mutual Exclusion.
CS425 /CSE424/ECE428 – Distributed Systems – Fall 2011 Material derived from slides by I. Gupta, M. Harandi, J. Hou, S. Mitra, K. Nahrstedt, N. Vaidya.
Presenter: Long Ma Advisor: Dr. Zhang 4.5 DISTRIBUTED MUTUAL EXCLUSION.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Today’s Agenda  HW #2 Out  Replay Semaphore and Lock  Advanced Locking Advanced Topics in Software Engineering 1.
CIS825 Lecture 2. Model Processors Communication medium.
D u k e S y s t e m s Asynchronous Replicated State Machines (Causal Multicast and All That) Jeff Chase Duke University.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
Fall 2008Programming Development Techniques 1 Topic 20 Concurrency Section 3.4.
Concurrency in Shared Memory Systems Synchronization and Mutual Exclusion.
Advanced Topics in Software Engineering1 Today’s Agenda  HW #1  Quick Review  Finish The CS Problem  Replay Shared Variables.
Event Ordering. CS 5204 – Operating Systems2 Time and Ordering The two critical differences between centralized and distributed systems are: absence of.
Lecture 12-1 Computer Science 425 Distributed Systems CS 425 / CSE 424 / ECE 428 Fall 2012 Indranil Gupta (Indy) October 4, 2012 Lecture 12 Mutual Exclusion.
Eraser: A dynamic Data Race Detector for Multithreaded Programs Stefan Savage, Michael Burrows, Greg Nelson, Patrick Sobalvarro, Thomas Anderson Presenter:
1 Processes and Threads Part II Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
1 Critical Section Problem CIS 450 Winter 2003 Professor Jinhua Guo.
Mutual Exclusion Algorithms. Topics r Defining mutual exclusion r A centralized approach r A distributed approach r An approach assuming an organization.
Agenda  Quick Review  Finish Introduction  Java Threads.
Introduction to distributed systems description relation to practice variables and communication primitives instructions states, actions and programs synchrony.
CS3771 Today: Distributed Coordination  Previous class: Distributed File Systems Issues: Naming Strategies: Absolute Names, Mount Points (logical connection.
Homework-6 Questions : 2,10,15,22.
Synchronization Questions answered in this lecture: Why is synchronization necessary? What are race conditions, critical sections, and atomic operations?
Detecting Data Races in Multi-Threaded Programs
Interprocess Communication Race Conditions
Healing Data Races On-The-Fly
Background on the need for Synchronization
CS533 Concepts of Operating Systems Class 3
Lecture 14: Pthreads Mutex and Condition Variables
Midterm review: closed book multiple choice chapters 1 to 9
Threading And Parallel Programming Constructs
Deadlock B.Ramamurthy CSE421 1/11/2019 B.Ramamurthy.
CSE 486/586 Distributed Systems Mutual Exclusion
CS533 Concepts of Operating Systems Class 3
Lecture 14: Pthreads Mutex and Condition Variables
Deadlock B.Ramamurthy CSE421 4/23/2019 B.Ramamurthy.
CSE 153 Design of Operating Systems Winter 19
Lecture 24: Multiprocessors
Deadlock B.Ramamurthy CSE421 5/1/2019 B.Ramamurthy.
Eraser: A dynamic data race detector for multithreaded programs
CSE 486/586 Distributed Systems Mutual Exclusion
Deadlock B.Ramamurthy CSE421 8/28/2019 B.Ramamurthy.
Deadlock B.Ramamurthy CSE421 9/3/2019 B.Ramamurthy.
Presentation transcript:

Today’s Agenda  Midterm: Nov 3 or 10  Finish Message Passing  Race Analysis Advanced Topics in Software Engineering 1

Advanced Topics in Software Engineering 2 Race Analysis  Introduction  The Lockset Algorithm  Message Race Detection

Advanced Topics in Software Engineering 3 Race Conditions Many factors, such as unpredictable process scheduling and variations in message latencies, can contribute to the non-deterministic behavior of concurrent programs. These factors can be informally referred to as race conditions or just races. The activity of identifying races is referred to as race analysis.

Advanced Topics in Software Engineering 4 General & Data Races There are two different types of races that capture different kinds of bugs. General races cause nondeterministic execution and are failures in programs intended to be deterministic. Data races cause non-atomic execution of critical sections and are failures in programs that access and update shared data in critical sections.

Advanced Topics in Software Engineering 5 Examples Process 1 /* deposit */ amount = read_amount (); P (mutex); balance = balance + amount; interest = interest + rate * balance; V (mutex); Process 2 /* withdraw */ amount = read_amount (); P (mutex); if (balance < amount) printf (“NSF”); else balance = balance – amount; interest = interest + rate * balance; V (mutex); Process 1 /* deposit */ amount = read_amount (); P (mutex); balance = balance + amount; interest = interest + rate * balance; V (mutex); Process 2 /* withdraw */ amount = read_amount (); if (balance < amount) printf (“NSF”); else balance = balance – amount; interest = interest + rate * balance;

Advanced Topics in Software Engineering 6 Race Analysis  Introduction  The Lockset Algorithm  Message Race Detection

Advanced Topics in Software Engineering 7 Locking Discipline A locking discipline is a programming policy that ensures the absence of data races. For example, a simple locking discipline is to require that every variable shared between threads is protected by a mutual exclusion lock. The lockset algorithm is to ensure that all shared- memory accesses follow the simple locking discipline.

Advanced Topics in Software Engineering 8 The Algorithm (1) For each shared variable v, the algorithm maintains the set C(v) of candidate locks as follows:  When a variable is initialized, C(v) contains all possible locks;  When a variable is accessed, C(v) is replaced with the intersection of C(v) and the set of locks held by the current thread.  If C(v) becomes empty, it signals that there is no lock that consistently protects v. (Otherwise, there is at least one lock that remains in C(v).)

Advanced Topics in Software Engineering 9 The Algorithm (2) for each shared variable v, initialize CandidateLocks(v) to the set of all locks On each read or write access to v by thread T CandidateLocks(v) = CandidateLocks(v)  LocksHeld (T) if (CandidateLocks(v) == {}) issue a warning.

Advanced Topics in Software Engineering 10 Example (1) Thread 1LocksHeld(Thread1)CandidateLocks(s) { }{ mutex1, mutex2} mutex1.lock();{ mutex1 }{ mutex1, mutex2 } s = s + 1;{ mutex1 }{ mutex1, mutex2} mutex1.unlock();{ }{ mutex1 } mutex2.lock();{ mutex2 }{ mutex1 } s = s + 2;{ mutex2 }{ } mutex2.unlock();{ }{ }

Advanced Topics in Software Engineering 11 Example (2) {}{mutex1, mutex2} mutex1.lock {mutex1} {mutex1, mutex2} read s {mutex1} write s {mutex1} mutex1.unlock {}{mutex1} mutex2.lock {mutex2}{mutex1} read s {mutex2} {} LocksHeldCandidateLocks

Advanced Topics in Software Engineering 12 False Alarms The simple locking discipline is strict, in the sense that some common programming practices violate this discipline and are still free from data races:  Initialization: Shared variables are frequently initialized without a lock.  Read-shared Data: Some shared variables are written during initialization and are read-only thereafter.

Advanced Topics in Software Engineering 13 Initialization There is no need for a thread to lock out others if no other can possibly hold a reference to the data being accessed. To avoid false alarms caused by unlocked writes during initialization, we delay the refinement of a location’s candidate set until after it has been initialized. However, there is no easy way of knowing initialization is complete. Any solution?

Advanced Topics in Software Engineering 14 Read-shared Data Since simultaneous reads of a shared variable by multiple threads are not races, there is also no need to protect variable if it is read-only. To avoid false alarms caused by unlocked read- sharing for such data, we report races only after an initialized variable has become write-shared by more than one thread.

Advanced Topics in Software Engineering 15 State Transitions virginexclusiveshared shared- modified rd/wr, first thread wr rd, new threadrd wr, new thread wr

Advanced Topics in Software Engineering 16 Race Analysis  Introduction  The Lockset Algorithm  Message Race Detection

Advanced Topics in Software Engineering 17 Asynchronous vs. Synchronous In an asynchronous message-passing program, each process uses non-blocking send and blocking receive operations to send and receive messages. This is in contrast with synchronous message- passing, where blocking send and blocking receive operations are used.

Advanced Topics in Software Engineering 18 Communication Scheme (1) A communication scheme may impose certain restrictions on the relationship between the order in which messages are sent and the order in which messages are received. The behavior of an asynchronous message-passing program depends on its underlying communication scheme.

Advanced Topics in Software Engineering 19 Communication Scheme (2) The fully asynchronous scheme allows that messages are received out of order. The FIFO scheme requires that messages exchanged between any two processes be received in the same order as they are sent. The causal scheme requires that all the messages are received in the same order as they are sent.

Advanced Topics in Software Engineering 20 SR-sequence An execution of an asynchronous message-passing program exercises a sequence of send and receive events, or an SR-sequence. Formally, an SR-sequence is defined as a triple (S, R, Y), where S is a set of send events, R a set of receive events, and Y a set of synchronizations.

Advanced Topics in Software Engineering 21 Example r1 P1P2P3 s1 s2 s3 r2 r3 s1 P1P2P3 s2 s3 r2 r1 r3 s2 P1P2 s1 r2 r1 CausalFIFOFully Asyn. Causal  FIFO  Fully Asyn. s4 r4 s5 r5

Advanced Topics in Software Engineering 22 Message Race (1) Informally, there exists a message race between two send events if the messages sent by the two events may be received by the same receive event. Given an SR-sequence, we can perform race analysis, and determine, for each receive event, the set of send events that may send messages to this receive event.

Advanced Topics in Software Engineering 23 Message Race (2) Message race shall be independent from program implementation. r1 P1P2P3 s1 r2 s2

Advanced Topics in Software Engineering 24 Message Race (3) Message race depends on the underlying communication scheme. r1 P1P2P3 s1 s2 s3 r2 r3 CausalFIFO or Asyn. r1 P1P2P3 s1 s2 s3 r2 r3

Advanced Topics in Software Engineering 25 Message Race Detection (1) Let P be an asynchronous message-passing program consisting of processes P1, P2,..., and Pn. Let Q be the SR-sequence exercised by one execution of P. Let r be a receive event in Q. Assume that r receives the message sent by a send event s in Q. A send event s’ is in the race set, race(r), of r if the message sent by s’ can be received by r in another execution. Race analysis of Q is to determine race(r) for every receive event r in Q.

Advanced Topics in Software Engineering 26 Message Race Detection (2) Assume that the fully asynchronous communication scheme is used. Let r be a receive event of Pi. A send event s of Pj is in race(r) if the following two conditions are met:  the message sent by s is destined to Pi.  r does not happen before s  if s is received by r’, then r must happen before r’.

Advanced Topics in Software Engineering 27 Message Race Detection (3) Assume that the FIFO communication scheme is used. Let r be a receive event of Pi. A send event s of Pj is in race(r) if the following three conditions are met:  the message sent by s is destined to Pi.  r does not happen before s  if s is received by r’, then r must happen before r’.  there does not exist another send event s’ of Pj such that s’ happens before s and s’ satisfies the above two conditions or is synchronized with r.

Advanced Topics in Software Engineering 28 Message Race Detection (4) Assume that the Causal communication scheme is used. Let r be a receive event of Pi. A send event s of Pj is in race(r) if the following three conditions are met:  the message sent by s is destined to Pi.  r does not happen before s  if s is received by r’, then r must happen before r’.  there does not exist another send event s’ of any process such that s’ happens before s and s’ satisfies the above two conditions or is synchronized with r.

Advanced Topics in Software Engineering 29 Message Race Detection (5) r1 P1P2P3 s1 s2 s3 r2r3 P4 s4 r4 s5 r5 s6 r6s7 r7 s8 r8