1 Operating Systems, 122 Practical Session 5, Synchronization 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

Operating Systems: Monitors 1 Monitors (C.A.R. Hoare) higher level construct than semaphores a package of grouped procedures, variables and data i.e. object.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
CSC321 Concurrent Programming: §3 The Mutual Exclusion Problem 1 Section 3 The Mutual Exclusion Problem.
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.
Mutual Exclusion By Shiran Mizrahi. Critical Section class Counter { private int value = 1; //counter starts at one public Counter(int c) { //constructor.
Chapter 6: Process Synchronization
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.
EEE 435 Principles of Operating Systems Interprocess Communication Pt II (Modern Operating Systems 2.3)
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
Mutual Exclusion.
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
Critical Section chapter3.
Chapter 3 The Critical Section Problem
Parallel Processing (CS526) Spring 2012(Week 6).  A parallel algorithm is a group of partitioned tasks that work with each other to solve a large problem.
CY2003 Computer Systems Lecture 05 Semaphores - Theory.
Operating Systems ECE344 Ding Yuan Synchronization (I) -- Critical region and lock Lecture 5: Synchronization (I) -- Critical region and lock.
1 Operating Systems, 112 Practical Session 5, Synchronization 1.
Synchronization Principles. Race Conditions Race Conditions: An Example spooler directory out in 4 7 somefile.txt list.c scores.txt Process.
Synchronization (other solutions …). Announcements Assignment 2 is graded Project 1 is due today.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
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.
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.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts Essentials – 9 th Edition Chapter 5: Process Synchronization.
CY2003 Computer Systems Lecture 04 Interprocess Communication.
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
Operating Systems CMPSC 473 Mutual Exclusion Lecture 11: October 5, 2010 Instructor: Bhuvan Urgaonkar.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-5 Process Synchronization Department of Computer Science and Software.
1 Critical Section Problem CIS 450 Winter 2003 Professor Jinhua Guo.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Implementing Mutual Exclusion Andy Wang Operating Systems COP 4610 / CGS 5765.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
Synchronization Questions answered in this lecture: Why is synchronization necessary? What are race conditions, critical sections, and atomic operations?
CSE 120 Principles of Operating
Practical Session 5 Synchronization
Process Synchronization
Chapter 5: Process Synchronization
Background on the need for Synchronization
Chapter 5: Process Synchronization
Designing Parallel Algorithms (Synchronization)
Practical Session 5 Synchronization
Topic 6 (Textbook - Chapter 5) Process Synchronization
Practical Session 5 Synchronization
UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department
Lecture 2 Part 2 Process Synchronization
Critical section problem
Practical Session 5, Synchronization
Implementing Mutual Exclusion
Concurrency: Mutual Exclusion and Process Synchronization
Implementing Mutual Exclusion
CSE 451: Operating Systems Autumn 2003 Lecture 7 Synchronization
CSE 451: Operating Systems Autumn 2005 Lecture 7 Synchronization
CSE 451: Operating Systems Winter 2003 Lecture 7 Synchronization
CSE 153 Design of Operating Systems Winter 19
CS333 Intro to Operating Systems
Chapter 6: Synchronization Tools
CSE 542: Operating Systems
Presentation transcript:

1 Operating Systems, 122 Practical Session 5, Synchronization 1

2 Motivation Multiprocessing needs some tools for managing shared resources – Printers – Files – Data Bases 2

3 Conditions for a good Solution 1.Mutual Exclusion critical section 1.Mutual Exclusion – No two processes are in the critical section (CS) at the same time 2.Deadlock Freedom one 2.Deadlock Freedom – If processes are trying to enter the CS one will eventually enter it 3.Starvation Freedom 3.Starvation Freedom – When a process tries to enter its CS, it will eventually succeed 3

4 Solution Archetypes Busy wait – Wastes CPU LR HR LRH H – Priority inversion with busy waiting ( * ): Task L (low priority) runs and gains exclusive use of resource R. H (high priority) task is introduced and attempts to acquire R and must therefore wait. Note that since H is busy waiting it may still be scheduled (its state remains runnable). Result: L can’t run and release R because H is of higher priority and is scheduled to run before it. H on the other hand can’t proceed past its busy wait loop. Deadlock! Sleep & Wake up – Also prone to priority inversion but will not deadlock. Can you think of a scenario? 4

5 Peterson’s Solution N=2; interested[0]=interested[1]=FALSE; int turn; /* Should be named NOT_MY_TURN */ int interested[N]; /* all initially 0 (FALSE) */ void enter_region(int process){ /* who is entering 0 or 1 ? */ int other = 1- process; /* opposite of process */ interested[process] = TRUE; /* signal that you're interested */ turn = process; /* set flag – NOT my turn */ while (turn == process && interested[other] == TRUE); /* null statement */ } void leave_region(int process){ /* who is leaving 0 or 1 ? */ interested[process] = FALSE ; /* departure from critical region */ } 5

6 Peterson’s Solution interested[0]=interested[1]=FALSE int turn; int interested[2]; void enter_region(…){ int other = 1; interested[0] = TRUE; turn = 0; while (turn == 0 && interested[1] == TRUE); } void leave_region(…){ interested[0] = FALSE;} 6 interested[0]=interested[1]=FALSE int turn; int interested[2]; void enter_region(…){ int other = 0; interested[1] = TRUE; turn = 1; while (turn == 1 && interested[0] == TRUE); } void leave_region(…){ interested[1] = FALSE;} Process = 0Process = 1

77 Question 1 N=1; interested[0]=interested[1]=FALSE; int turn; /* Should be named NOT_MY_TURN */ int interested[N];/* all initially 0 (FALSE) */ void enter_region(int process){ /* who is entering 0 or 1 ? */ int other = 1- process;/* opposite of process */ turn = process; interested[process] = TRUE; turn = process; /* set flag – NOT my turn */ interested[process] = TRUE; /* signal that you're interested */ while (turn == process && interested[other] == TRUE); /* null statement */ } void leave_region(int process){/* who is leaving 0 or 1 ? */ interested[process] = FALSE; /* departure from critical region */ } Consider the following variant of Peterson’s solution where the two red lines are swapped. Does this variant solve the mutual exclusion problem?

8 Peterson’s Solution 8 Process = 0Process = 1 interested[0]=interested[1]=FALSE int turn; int interested[2];

9 Answer We will get a mutual exclusion violation: P1 does turn:=1; P0 does turn:=0; P0 does interested[0]:=true; P0 does while(turn == 0 && interested [1]); // (#t and #f)  #f P0 enters the CS. P1 does interested [1]:=true; P1 does while(turn == 1 && interested [0]); // (#f and #t)  #f P1 enters the CS. now both processes are in the critical section. 9

10 Question 2 Assume the while statement in Peterson's solution is changed to: while (turn != process && interested[other] == TRUE) Describe a scheduling scenario in which we will receive a mutual exclusion violation and one in which we will NOT receive a Mutual Exclusion violation. 10

11 Question 2 N=2; interested[0]=interested[1]=FALSE; int turn; /* Should be named NOT_MY_TURN */ int interested[N]; /* all initially 0 (FALSE) */ while (turn != process && void enter_region(int process){ /* who is entering 0 or 1 ? */ int other = 1- process; /* opposite of process */ interested[process] = TRUE; /* signal that you're interested */ turn = process; /* set flag – NOT my turn */ while (turn != process && interested[other] == TRUE) interested[other] == TRUE) /* null statement */ } void leave_region(int process){ /* who is leaving 0 or 1 ? */ interested[process] = FALSE ; /* departure from critical region */ } 11

12 Peterson’s Solution 12 Process = 0Process = 1 interested[0]=interested[1]=FALSE int turn; int interested[2];

13 Answer for Q.2 No mutual exclusion violation: 1.One enters and exits and only afterwards the second receives a time quanta. 2. P0 – interested[0]=true, P0 – turn = 0, P1- interested[1]=true, P1 – turn =1, P1 passes while loop and enters CS, P0 – stuck in while loop. 3. Many more…. 13

14 Answer for Q.2 Mutual exclusion violation: Process A executes: interested [process] = TRUEturn = process `interested [process] = TRUE', `turn = process‘ and falls through the while loop shown above. While in the critical section, the timer fires and process B executes: interested [process] = TRUEturn = process `interested [process] = TRUE', `turn = process' and falls through the while loop shown above. Both processes are in the critical section. 14

15 Dekker’s algorithm 1.bool* flag = {false, false}; 2.int turn = 0 ; 3.void mutex() { 4.flag[process] = true; 5.while (flag[1-process]) { 6. if (turn==(1-process)) { 7. flag[process] = false; 8. while (turn == (1-process)) { /*nothing*/ } 9. flag[process] = true;}} 10./* critical section */ 11.turn = (1-process); 12.flag[process] = false; 13./* non-critical section */ } 15

Question 3 (from midterm of 2005) Prove Dekker’s algorithm for the Critical Section problem. That is, show that there are no mutual exclusion violations, no deadlocks and no starvation problem. 16

17 Question 3 (from midterm of 2005) 1.bool* flag = {false, false}; 2.int turn = 0 ; 3.void mutex() { 4.flag[0] = true; 5.while (flag[1]) { 6. if (turn==1) { 7. flag[0] = false; 8. while (turn == 1) {} 9. flag[0] = true;}} 10./* critical section */ 11.turn = 1; 12.flag[0] = false; 13./* non-critical section */ } 17 Process = 0Process = 1 1.bool* flag = {false, false}; 2.int turn = 0 ; 3.void mutex() { 4.flag[1] = true; 5.while (flag[0]) { 6. if (turn==0) { 7. flag[1] = false; 8. while (turn == 0) {} 9. flag[1] = true;}} 10./* critical section */ 11.turn = 0; 12.flag[1] = false; 13./* non-critical section */ }

18 No mutual exclusion violations No mutual exclusion violations – (no two processes will be in the CS at the same time) Falsely assume that both p 0 and p 1 are in the critical section. Further assume WLG that p 0 entered the CS first. change flag[0]=true The last change p 0 introduced on the algorithm’s variables, before existing the outer loop (line 5), was the assignment flag[0]=true. flag[0]=false Following our assumption, p 1 followed p 0 into the CS which means that it must have exited its outer loop. This, however, is only possible if flag[0]=false which is a contradiction to our initial assumption. 18 Answer Q.3

19 No starvation No starvation – (any process attempting to enter the CS will eventually succeed) WLG assume p 0 is attempting to enter the CS and is somewhere in the while loop of line 5 (otherwise it will enter the CS). p1 can be in several different states: 1.Not in the CS 2.In the CS turn=0 3.In its while loop with turn=0 turn=1 4.In its while loop with turn=1 19 Answer Q.3

20 Case 1 Case 1 – a process not in the CS will not prevent other processes from entering it flag[i]=false Any process which is not in the CS and does not want to enter it turns off its flag flag[i]=false (line 12 or init). while(flag[1]) turn This implies that any other process wishing to enter the CS will find the condition on the outer while loop (line 5, “while(flag[1])”) unsatisfied and will be able to enter the CS without having to examine the value of turn. 20 Answer Q.3

21 Case 2 Case 2 – p1 is in the CS turn turn=0 After a finite amount of time p1 will exit the CS and will set the value of turn to turn=0. If it stays out then we are back to case 1. turn=0 Otherwise, if there is no preemption p 1 may try to enter the CS and we have to consider case 3 (p1 is in its while loop with turn=0). 21 Answer Q.3

22 Case 3 Case 3 – p 1 is in its while loop with turn=0 turn turn flag[1]=false Since the value of turn is 0, and no process can change it (p 0 is attempting to enter the CS and will only be able to change turn’s value after it leaves the CS), p 1 will eventually be held by the inner while loop (line 8) after setting flag[1]=false. turn flag[1]=false At some point, p 0 will receive CPU time. Since the value of turn is 0, it will proceed to its outer while loop (line 5). At this point the outer loop condition will not hold it, since flag[1]=false (by p 1 ), and p 0 will proceed to the CS. 22 Answer Q.3

23 Case 4 Case 4 – p 1 is in its while loop with turn=1 turn flag[0]=true If the value of turn is 1, then p 1 will revolve in its outer while loop (line 5). It will continue going through it as long as flag[0]=true. turn flag[0]=false At some point, p 0 will receive CPU time. Since the value of turn is 1, it will proceed to its inner while loop (line 8) after setting flag[0]=false. At this point the outer loop condition will not hold p 1, and we will be back to case 2 or 3 (for which we have shown that p 0 may eventually enter the CS). 23 Answer Q.3

24 No Deadlock No need to prove! Follows from the fact that there’s no starvation. 24 Answer Q.3

25 Lamport’s Bakery Algorithm int value[N]={0, 0,…,0};/* processes get “waiting numbers” */ int busy[N]={FALSE,…, FALSE};/* just a flag... */ void enter_region(int i ) /* process i entering.. */ { busy[i] = TRUE;/* guard the value selection */ value[i] = max(value[0], value[1], …, value[N-1]) + 1; /* LAST in line … */ busy[i] = FALSE; for(k=0; k < N; k ++){ while (busy[k] == TRUE) ; /* wait before checking */ while((value[k] != 0) && ((value[k], k) < (value[i], i)));/* wait */ } void leave_region(int i ) { value[i ] = 0; } 25

26 Question 4 atomic command Assume we have the following atomic command: void swap(bool *a, bool *b) { bool temp = *a; *a = *b; *b = temp; } Solve the N processes mutual exclusion problem using the swap command. 26

27 Answer Q.4 bool lock = FALSE; bool waiting[N] = {FALSE, FALSE, …, FALSE}; void enter(int i) { waiting[i] = TRUE; bool key = TRUE; while (TRUE) { swap(&key, &lock); if ( !waiting[i] || !key) break; } } 27 void leave(int i) { waiting[i]= FALSE ; int j = (i + 1) % N; while ( (j != i) && waiting[j]==FALSE ) { j = (j + 1) % N; } if (j == i) { lock = FALSE; } else { waiting[j] = FALSE; } } void swap(bool *a, bool *b) { bool temp = *a; *a = *b; *b = temp; } The idea: Use a local variable “key” which will be set to true. Let all processes swap it with current lock and compete over this line. Only the first process to grab it will have a value of false to the lock. This process will enter the CS. The idea: Seek the next (chronologically ordered) interested process. If such a process exist, grant it the ability to enter the CS. Otherwise reset the lock so that other processes will be able to enter the CS at a later time.

Question 5a – midterm 2010 n processes Let A be an n processes (finite) mutual exclusion algorithm which is applied with the following guarantee: whenever A is used, any process will attempt to access the critical section only once. Prove or disprove the following claim: if and only if A is a starvation free algorithm if and only if it is a deadlock free algorithm. 28

Answer Q.5a The first part of the proof is trivial: starvation freedom also implies deadlock freedom. What about the second one? not Assume that there are n processes and that A is free of deadlocks. Now, let us falsely assume that A is not a starvation free algorithm and contradict this assumption. If A is not a starvation free algorithm, then there must exist some process p i which goes through infinitely many steps but still can’t enter the CS. 29

Answer Q.5a, continued While p i goes through its steps other processes manage to enter the CS (we assumed deadlock freedom). As each process p j may only enter the CS once, at some point all n-1 processes will go through (in and out of) the CS and we will be left with p i. At this point, p i is the only process attempting to enter the CS. Following our initial assumption, there can be no deadlocks and p i will enter the CS. This contradicts our false assumption that A is not a starvation free algorithm. QED 30

Question Q.5b – midterm 2010 Consider the following simple algorithm similar to that shown in class: Is this algorithm deadlock free? Prove or disprove by providing an accurate scenario which leads to a deadlock. 31 Test-and-set Test-and-set(w) do atomically prev:=w w:=1 return prev 1 int lock initially 0 2 boolean interested[n] initially {false,…,false} Code for procss i  {0,…,n-1} 3 interested[i]:=true 4 await ((test-and-set(lock)=0) OR (interested[i] =false)) Critical Section 5 Critical Section 6 j:=(i+1) modulo n 7 while (j ≠ i) AND (interested[j] = false) 8 j:=(j+1) modulo n 9 if (j=i) 10 lock:=0 11 else 12 interested[j]:=false 13 interested[i]=false

Answer Q.5b deadlock The following scenario results in a deadlock: lock 1.A process p 0 is executed and executes all lines up until the beginning of line 13. (Note that ‘lock’ is freed) 2.Another process p 1 is executed and allowed to run all the way through the CS. At this point p 1 iterates through the other processes and identifies that ‘interested[0]=true’. 3.As a result p 1 resets the value ‘interested[0]:=false’ (line 12) and does not free the lock. It then proceeds to line 13 and exits. 4.p 0 runs line At this point the system is in a state of deadlock. Any process attempting to enter the CS will be stopped by line 4. 32

ASSIGNMENT 2 Overview

Assignment 2- overview The assignment consists of three parts: 1.Implementing a cooperative User-level threads package 2.Implementing a Kernel-level threads package – Synchronization primitives: mutex, condition variable 3.Solving a synchronization problem - a variant of the dining philosophers' problem with a producer-consumer scheme – Two variants: using the user threads package and using the kernel threads package. 4.Comparing performance

User threads User threads are cooperative (not preemptive). Context switch is explicitly triggered by calling yield. In our implementation the context of a user thread consists of its unique stack and a pointer to its top. Context switch is achieved by changing the value of the esp register so that it points to the top of the stack of another thread. 35

User threads cont’d Thread A’s code: Instruction n; yield(); Instruction m; Thread B’s code: Instruction i;yield(); Instruction j; 36 Yield schedules thread B to run next. Here we assume that it already ran, and called yield in the past. Addr of inst m Old ebp Local vars esp Thread A’ stack Addr of inst j Old ebp Local vars top Thread B’ stack Yield code: 1.Store esp to current_thread struct 2.Pick another thread as current_thread 3.Load new esp

User threads cont’d Thread A’s code: Instruction n; yield(); Instruction m; Thread B’s code: Instruction i;yield(); Instruction j; 37 Yield schedules thread B to run next. We assume that it already ran, and called yield in the past. Addr of inst m Old ebp Local vars esp Thread A’ stack Addr of inst j Old ebp Local vars top Thread B’ stack Yield code: 1.Store esp to current_thread struct 2.Pick another thread as current_thread 3.Load new esp

User threads cont’d After the esp is switched, yield continues on thread B’s stack. thread B When yield finishes, the program flow returns to where thread B has stopped (next instruction after the call to yield). 38

Kernel threads Based on the xv6’s process implementation. Represented by struct proc and managed by the kernel. To create a thread use a code similar to fork. To achieve a thread-like behavior the newly created “process” shares the same virtual address space as its “parent process”. 39