1 Thread Synchronization: Too Much Milk. 2 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing.

Slides:



Advertisements
Similar presentations
Synchronization NOTE to instructors: it is helpful to walk through an example such as readers/writers locks for illustrating the use of condition variables.
Advertisements

Operating Systems Part III: Process Management (Process Synchronization)
Synchronization. How to synchronize processes? – Need to protect access to shared data to avoid problems like race conditions – Typical example: Updating.
Process Synchronization A set of concurrent/parallel processes/tasks can be disjoint or cooperating (or competing) With cooperating and competing processes.
PROCESS SYNCHRONIZATION READINGS: CHAPTER 5. ISSUES IN COOPERING PROCESSES AND THREADS – DATA SHARING Shared Memory Two or more processes share a part.
Process Synchronization Continued 7.2 The Critical-Section Problem.
Mutual Exclusion By Shiran Mizrahi. Critical Section class Counter { private int value = 1; //counter starts at one public Counter(int c) { //constructor.
Silberschatz, Galvin and Gagne ©2007 Operating System Concepts with Java – 7 th Edition, Nov 15, 2006 Chapter 6 (a): Synchronization.
Previously… Processes –Process States –Context Switching –Process Queues Threads –Thread Mappings Scheduling –FCFS –SJF –Priority scheduling –Round Robin.
Chapter 6 Process Synchronization Bernard Chen Spring 2007.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Multiprocessor Synchronization Algorithms ( ) Lecturer: Danny Hendler The Mutual Exclusion problem.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
Operating System Concepts and Techniques Lecture 12 Interprocess communication-1 M. Naghibzadeh Reference M. Naghibzadeh, Operating System Concepts and.
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
China’s Software Industry August 2006 Instructor: Hengming Zou, Ph.D.
1 Mutual Exclusion: Primitives and Implementation Considerations.
CIS 720 Mutual Exclusion. Critical Section problem Process i do (true) entry protocol; critical section; exit protocol; non-critical section od.
Concurrency.
Race Conditions Critical Sections Deker’s Algorithm.
Shared Memory Coordination We will be looking at process coordination using shared memory and busy waiting. –So we don't send messages but read and write.
Race Conditions Critical Sections Dekker’s Algorithm.
University of Pennsylvania 9/19/00CSE 3801 Concurrent Processes CSE 380 Lecture Note 4 Insup Lee.
Synchronization (other solutions …). Announcements Assignment 2 is graded Project 1 is due today.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Operating Systems CMPSCI 377 Lecture.
Synchronization CSCI 444/544 Operating Systems Fall 2008.
1 Race Conditions/Mutual Exclusion Segment of code of a process where a shared resource is accessed (changing global variables, writing files etc) is called.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
Synchronization Andy Wang Operating Systems COP 4610 / CGS 5765.
Concurrency Recitation – 2/24 Nisarg Raval Slides by Prof. Landon Cox.
9/8/2015cse synchronization-p1 © Perkins DW Johnson and University of Washington1 Synchronization Part 1 CSE 410, Spring 2008 Computer Systems.
1 Lecture 9: Synchronization  concurrency examples and the need for synchronization  definition of mutual exclusion (MX)  programming solutions for.
The Critical Section Problem
28/10/1999POS-A1 The Synchronization Problem Synchronization problems occur because –multiple processes or threads want to share data; –the executions.
Process Synchronization Continued 7.2 Critical-Section Problem 7.3 Synchronization Hardware 7.4 Semaphores.
COMP 111 Threads and concurrency Sept 28, Tufts University Computer Science2 Who is this guy? I am not Prof. Couch Obvious? Sam Guyer New assistant.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
11/18/20151 Operating Systems Design (CS 423) Elsa L Gunter 2112 SC, UIUC Based on slides by Roy Campbell, Sam.
Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
CSCI-375 Operating Systems Lecture Note: Many slides and/or pictures in the following are adapted from: slides ©2005 Silberschatz, Galvin, and Gagne Some.
1 Lecture 8: Concurrency: Mutual Exclusion and Synchronization Advanced Operating System Fall 2012.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-5 Process Synchronization Department of Computer Science and Software.
U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Computer Systems Principles Synchronization Emery Berger and Mark Corner University.
CPS110: Thread cooperation Landon Cox. Constraining concurrency  Synchronization  Controlling thread interleavings  Some events are independent  No.
1 Critical Section Problem CIS 450 Winter 2003 Professor Jinhua Guo.
Concurrency: Locks and synchronization Slides by Prof. Cox.
Synchronization Questions answered in this lecture: Why is synchronization necessary? What are race conditions, critical sections, and atomic operations?
Chapter 6 Synchronization Dr. Yingwu Zhu. The Problem with Concurrent Execution Concurrent processes (& threads) often access shared data and resources.
6/27/20161 Operating Systems Design (CS 423) Elsa L Gunter 2112 SC, UIUC Based on slides by Roy Campbell, Sam King,
Synchronization Mutual Exclusion Solutions using shared variables + problems such as deadlocks, starvation, progressiveness, busy wait Prof. R K Joshi.
CS703 – Advanced Operating Systems
Background on the need for Synchronization
COMPSCI210 Recitation 12 Oct 2012 Vamsi Thummala
143a discussion session week 3
Race Conditions Critical Sections Dekker’s Algorithm
Designing Parallel Algorithms (Synchronization)
Andy Wang Operating Systems COP 4610 / CGS 5765
Critical Sections User Software Solutions Dekker’s Algorithm
CSE 153 Design of Operating Systems Winter 19
CS333 Intro to Operating Systems
Chapter 6: Synchronization Tools
Lecture 20: Synchronization
What is the meaning of process synchronization
Process/Thread Synchronization (Part 2)
CPS110: Thread cooperation
Don Porter Portions courtesy Emmett Witchel
Presentation transcript:

1 Thread Synchronization: Too Much Milk

2 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing mutual exclusion with memory reads and writes  Hardware support is needed The code must work all of the time  Most concurrency bugs generate correct results for some interleavings Designing mutual exclusion in software shows you how to think about concurrent updates  Always look for what you are checking and what you are updating  A meddlesome thread can execute between the check and the update, the dreaded race condition

3 Thread Coordination Jack Look in the fridge; out of milk Go to store Buy milk Arrive home; put milk away Jill Look in fridge; out of milk Go to store Buy milk Arrive home; put milk away Oh, no! Too much milk! Fridge and milk are shared data structures

4 Formalizing “Too Much Milk” Shared variables  “Look in the fridge for milk” – check a variable  “Put milk away” – update a variable Safety property  At most one person buys milk Liveness  Someone buys milk when needed How can we solve this problem?

5 How to think about synchronization code Every thread has the same pattern  Entry section: code to attempt entry to critical section  Critical section: code that requires isolation (e.g., with mutual exclusion)  Exit section: cleanup code after execution of critical region  Non-critical section: everything else There can be multiple critical regions in a program  Only critical regions that access the same resource (e.g., data structure) need to synchronize with each other while(1) { Entry section Critical section Exit section Non-critical section }

6 The correctness conditions Safety  Only one thread in the critical region Liveness  Some thread that enters the entry section eventually enters the critical region  Even if some thread takes forever in non-critical region Bounded waiting  A thread that enters the entry section enters the critical section within some bounded number of operations. Failure atomicity  It is OK for a thread to die in the critical region  Many techniques do not provide failure atomicity while(1) { Entry section Critical section Exit section Non-critical section }

7 Too Much Milk: Solution #0 Is this solution  1. Correct  2. Not safe  3. Not live  4. No bounded wait  5. Not safe and not live It works sometime and doesn’t some other times while(1) { if (noMilk) { // check milk (Entry section) if (noNote) { // check if roommate is getting milk leave Note; //Critical section buy milk; remove Note; // Exit section } // Non-critical region } while(1) { if (noMilk) { // check milk (Entry section) if (noNote) { // check if roommate is getting milk leave Note; //Critical section buy milk; remove Note; // Exit section } // Non-critical region } What if we switch the order of checks?

8 Too Much Milk: Solution #1 while(1) { while(turn ≠ Jack) ; //spin while (Milk) ; //spin buy milk; // Critical section turn := Jill // Exit section // Non-critical section } while(1) { while(turn ≠ Jack) ; //spin while (Milk) ; //spin buy milk; // Critical section turn := Jill // Exit section // Non-critical section } while(1) { while(turn ≠ Jill) ; //spin while (Milk) ; //spin buy milk; turn := Jack // Non-critical section } while(1) { while(turn ≠ Jill) ; //spin while (Milk) ; //spin buy milk; turn := Jack // Non-critical section } Is this solution  1. Correct  2. Not safe  3. Not live  4. No bounded wait  5. Not safe and not live At least it is safe turn := Jill // Initialization

9 Solution #2 (a.k.a. Peterson’s algorithm): combine ideas of 0 and 1 Variables:  in i : thread T i is executing, or attempting to execute, in CS  turn:id of thread allowed to enter CS if multiple want to Claim: We can achieve mutual exclusion if the following invariant holds before entering the critical section: {(¬in j  (in j  turn = i))  in i } CS ……… in i = false ((¬in 0  (in 0  turn = 1))  in 1 )  ((¬in 1  (in 1  turn = 0))  in 0 )  ((turn = 0)  (turn = 1))  false

10 Peterson’s Algorithm Safe, live, and bounded waiting But, only 2 participants Jack while (1) { in 0 := true; turn := Jack; while (turn == Jack && in 1 ) ;//wait Critical section in 0 := false; Non-critical section } Jack while (1) { in 0 := true; turn := Jack; while (turn == Jack && in 1 ) ;//wait Critical section in 0 := false; Non-critical section } Jill while (1) { in 1 := true; turn := Jill; while (turn == Jill && in 0 );//wait Critical section in 1 := false; Non-critical section } Jill while (1) { in 1 := true; turn := Jill; while (turn == Jill && in 0 );//wait Critical section in 1 := false; Non-critical section } in 0 = in 1 = false;

11 Too Much Milk: Lessons Peterson’s works, but it is really unsatisfactory  Limited to two threads  Solution is complicated; proving correctness is tricky even for the simple example  While thread is waiting, it is consuming CPU time How can we do better?  Use hardware to make synchronization faster  Define higher-level programming abstractions to simplify concurrent programming

12 Towards a solution The problem boils down to establishing the following right after entry i (¬in j  (in j  turn = i))  in i = (¬in j  turn = i)  in i How can we do that? entry i = in i := true; while (in j  turn ≠ i);

13 We hit a snag Thread T 0 while (!terminate) { in 0 := true {in 0 } while (in 1  turn ≠ 0); {in 0  (¬ in 1  turn = 0)} CS 0 ……… } Thread T 1 while (!terminate) { in 1 := true {in 1 } while (in 0  turn ≠ 1); {in 1  (¬ in 0  turn = 1)} CS 1 ……… } The assignment to in 0 invalidates the invariant!

14 What can we do? Thread T 0 while (!terminate) { in 0 := true; turn := 1; {in 0 } while (in 1  turn ≠ 0); {in 0  (¬ in 1  turn = 0  at(  1 ) )} CS 0 in 0 := false; NCS 0 } Thread T 0 while (!terminate) { in 0 := true; turn := 1; {in 0 } while (in 1  turn ≠ 0); {in 0  (¬ in 1  turn = 0  at(  1 ) )} CS 0 in 0 := false; NCS 0 } Thread T 1 while (!terminate) { in 1 := true; turn := 0; {in 1 } while (in 0  turn ≠ 1); {in 1  (¬ in 0  turn = 1  at(  0 ) )} CS 1 in 1 := false; NCS 1 } Thread T 1 while (!terminate) { in 1 := true; turn := 0; {in 1 } while (in 0  turn ≠ 1); {in 1  (¬ in 0  turn = 1  at(  0 ) )} CS 1 in 1 := false; NCS 1 } Add assignment to turn to establish the second disjunct 00 11

15 Safe? Thread T 0 while (!terminate) { in 0 := true; turn := 1; {in 0 } while (in 1  turn ≠ 0); {in 0  (¬ in 1  turn = 0  at(  1 ) )} CS 0 in 0 := false; NCS 0 } Thread T 0 while (!terminate) { in 0 := true; turn := 1; {in 0 } while (in 1  turn ≠ 0); {in 0  (¬ in 1  turn = 0  at(  1 ) )} CS 0 in 0 := false; NCS 0 } Thread T 1 while (!terminate) { in 1 := true; turn := 0; {in 1 } while (in 0  turn ≠ 1); {in 1  (¬ in 0  turn = 1  at(  0 ) )} CS 1 in 1 := false; NCS 1 } Thread T 1 while (!terminate) { in 1 := true; turn := 0; {in 1 } while (in 0  turn ≠ 1); {in 1  (¬ in 0  turn = 1  at(  0 ) )} CS 1 in 1 := false; NCS 1 } 00 11 If both in CS, then in 0  (¬in 1  at(  1 )  turn = 0)  in 1  (¬in 0  at(  0 )  turn = 1)   ¬ at(  0 )  ¬ at(  1 ) = (turn = 0)  (turn = 1) = false

16 Live? Thread T 0 while (!terminate) { {S 1 : ¬in 0  (turn = 1  turn = 0)} in 0 := true; {S 2 : in 0  (turn = 1  turn = 0)} turn := 1; {S 2 } while (in 1  turn ≠ 0); {S 3 : in 0  (¬ in 1  at(  1 )  turn = 0)} CS 0 {S 3 } in 0 := false; {S 1 } NCS 0 } Thread T 0 while (!terminate) { {S 1 : ¬in 0  (turn = 1  turn = 0)} in 0 := true; {S 2 : in 0  (turn = 1  turn = 0)} turn := 1; {S 2 } while (in 1  turn ≠ 0); {S 3 : in 0  (¬ in 1  at(  1 )  turn = 0)} CS 0 {S 3 } in 0 := false; {S 1 } NCS 0 } Thread T 1 while (!terminate) { {R 1 : ¬in 0  (turn = 1  turn = 0)} in 1 := true; {R 2 : in 0  (turn = 1  turn = 0)} turn := 0; {R 2 } while (in 0  turn ≠ 1); {R 3 : in 1  (¬ in 0  at(  0 )  turn = 1)} CS 1 {R 3 } in 1 := false; {R 1 } NCS 1 } Thread T 1 while (!terminate) { {R 1 : ¬in 0  (turn = 1  turn = 0)} in 1 := true; {R 2 : in 0  (turn = 1  turn = 0)} turn := 0; {R 2 } while (in 0  turn ≠ 1); {R 3 : in 1  (¬ in 0  at(  0 )  turn = 1)} CS 1 {R 3 } in 1 := false; {R 1 } NCS 1 } 00 11 Non-blocking: T 0 before NCS 0, T 1 stuck at while loop S 1  R 2  in 0  (turn = 0) = ¬in 0  in 1  in 0  (turn = 0) = false Deadlock-free: T 1 and T 0 at while, before entering the critical section S 2  R 2  (in 0  (turn = 0))  (in 1  (turn = 1))  (turn = 0)  (turn = 1) = false

17 Bounded waiting? Yup! Thread T 0 while (!terminate) { in 0 := true; turn := 1; while (in 1  turn ≠ 0); CS 0 in 0 := false; NCS 0 } Thread T 0 while (!terminate) { in 0 := true; turn := 1; while (in 1  turn ≠ 0); CS 0 in 0 := false; NCS 0 } Thread T 1 while (!terminate) { in 1 := true; turn := 0; while (in 0  turn ≠ 1); CS 0 in 1 := false; NCS 0 } Thread T 1 while (!terminate) { in 1 := true; turn := 0; while (in 0  turn ≠ 1); CS 0 in 1 := false; NCS 0 }