1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

1 Interprocess Communication 1. Ways of passing information 2. Guarded critical activities (e.g. updating shared data) 3. Proper sequencing in case of.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Ch 7 B.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
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.
Chapter 6: Process Synchronization
Background Concurrent access to shared data can lead to inconsistencies Maintaining data consistency among cooperating processes is critical What is wrong.
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.
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.
Secure Operating Systems Lesson 5: Shared Objects.
CY2003 Computer Systems Lecture 05 Semaphores - Theory.
Enforcing Mutual Exclusion Message Passing. Peterson’s Algorithm for Processes P0 and P1 void P0() { while( true ) { flag[ 0 ] = false; /* remainder */
5.6 Semaphores Semaphores –Software construct that can be used to enforce mutual exclusion –Contains a protected variable Can be accessed only via wait.
Avishai Wool lecture Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication.
5.6 Semaphores Semaphores –Software construct that can be used to enforce mutual exclusion –Contains a protected variable Can be accessed only via wait.
Synchronization Principles. Race Conditions Race Conditions: An Example spooler directory out in 4 7 somefile.txt list.c scores.txt Process.
Monitors CSCI 444/544 Operating Systems Fall 2008.
Semaphores CSCI 444/544 Operating Systems Fall 2008.
Race Conditions CS550 Operating Systems. Review So far, we have discussed Processes and Threads and talked about multithreading and MPI processes by example.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
CS Introduction to Operating Systems
18/02/08Week 21 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
Object Oriented Analysis & Design SDL Threads. Contents 2  Processes  Thread Concepts  Creating threads  Critical sections  Synchronizing threads.
© 2004, D. J. Foreman 1 High Level Synchronization and Inter-Process Communication.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion.
6.3 Peterson’s Solution The two processes share two variables: Int turn; Boolean flag[2] The variable turn indicates whose turn it is to enter the critical.
4061 Session 23 (4/10). Today Reader/Writer Locks and Semaphores Lock Files.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts Essentials – 9 th Edition Chapter 5: Process Synchronization.
CENG334 Introduction to Operating Systems
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Lecture 11: Synchronization (Chapter 6, cont)
1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:
Operating Systems CSE 411 CPU Management Dec Lecture Instructor: Bhuvan Urgaonkar.
13/03/07Week 21 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
CSCI1600: Embedded and Real Time Software Lecture 17: Concurrent Programming Steven Reiss, Fall 2015.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
© 2004, D. J. Foreman 1 Monitors and Inter-Process Communication.
Homework-6 Questions : 2,10,15,22.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion Mutexes, Semaphores.
1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Synchronization Semaphores
Process Synchronization: Semaphores
PARALLEL PROGRAM CHALLENGES
Background on the need for Synchronization
Operating Systems CMPSC 473
Chapter 5: Process Synchronization
Inter-Process Communication and Synchronization
Lecture 14: Pthreads Mutex and Condition Variables
Topic 6 (Textbook - Chapter 5) Process Synchronization
Threading And Parallel Programming Constructs
Lecture 2 Part 2 Process Synchronization
Critical section problem
CSE 153 Design of Operating Systems Winter 19
Chapter 6: Synchronization Tools
“The Little Book on Semaphores” Allen B. Downey
Process/Thread Synchronization (Part 2)
Operating Systems {week 10}
Presentation transcript:

1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL: Peterson’s algorithm Topics:

2 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); turn : indicates whose turn is it to enter critical section. If turn==i process Pi is allowed to get in. flag[2]: indicates if process Pi is ready to enter critical section. If flag[i]is set, then Pi is ready to enter critical section.

3 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); Mutual Exclusion: Only one process Pi (the one which set turn=i last) enters the critical section.

4 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); Progress: If process P1 is not in critical section then flag[1] = 0. Therefore while loop of P0 quits immediately and P0 can get into its critical section. And vice versa.. Bounded waiting: Process Pi keeps waiting in spinlocking only while the other process is in its critical section.

5 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); Uses spinlocking for waiting. No strict alternation is required between processes. That is, P0,P0,P0,P1,P1 is doable. Requires that processes alternate between critical and remainder sections. Can be extended to n processes, only if n is known apriori (in advance). HOW?

6 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); Prone to priority inversion: Assume that P0 has a higher priority than P1. When P1 is in its critical section, P0 may get scheduled to do spinlocking. P1 never gets scheduled to finish its critical section and both processes end up waiting.

7 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL: Synchronization patterns Topics Signalling Rendezvous Barrier

8 Signalling Possibly the simplest use for a semaphore is signaling, which means that one thread sends a signal to another thread to indicate that something has happened. Signaling makes it possible to guarantee that a section of code in one thread will run before a section of code in another thread; in other words, it solves the serialization problem. Adapted from The Little Book of Semaphores.

9 Signalling Imagine that a1 reads a line from a file, and b1 displays the line on the screen. The semaphore in this program guarantees that Thread A has completed a1 before Thread B begins b1. Here’s how it works: if thread B gets to the wait statement first, it will find the initial value, zero, and it will block. Then when Thread A signals, Thread B proceeds. Similarly, if Thread A gets to the signal first then the value of the semaphore will be incremented, and when Thread B gets to the wait, it will proceed immediately. Either way, the order of a1 and b1 is guaranteed. Thread A statement a1; sem.up(); Thread B sem.down(); statement b1; semaphore sem=0; Adapted from The Little Book of Semaphores.

10 Rendezvous Generalize the signal pattern so that it works both ways. Thread A has to wait for Thread B and vice versa. In other words, given this code we want to guarantee that a1 happens before b2 and b1 happens before a2. Your solution should not enforce too many constraints. For example, we don’t care about the order of a1 and b1. In your solution, either order should be possible. Two threads rendezvous at a point of execution, and neither is allowed to proceed until both have arrived. Thread A statement a1; statement a2; Thread B statement b1; statement b2; Adapted from The Little Book of Semaphores.

11 Rendezvous - Hint Generalize the signal pattern so that it works both ways. Thread A has to wait for Thread B and vice versa. In other words, given this code we want to guarantee that a1 happens before b2 and b1 happens before a2. Your solution should not enforce too many constraints. For example, we don’t care about the order of a1 and b1. In your solution, either order should be possible. Two threads rendezvous at a point of execution, and neither is allowed to proceed until both have arrived. Hint: Create two semaphores, named aArrived and bArrived, and initialize them both to zero. aArrived indicates whether Thread A has arrived at the rendezvous, and bArrived likewise. Thread A statement a1; statement a2; Thread B statement b1; statement b2; semaphore aArrived=0; semaphore bArrived=0; Adapted from The Little Book of Semaphores.

12 Rendezvous - Solution Generalize the signal pattern so that it works both ways. Thread A has to wait for Thread B and vice versa. In other words, given this code we want to guarantee that a1 happens before b2 and b1 happens before a2. Your solution should not enforce too many constraints. For example, we don’t care about the order of a1 and b1. In your solution, either order should be possible. Two threads rendezvous at a point of execution, and neither is allowed to proceed until both have arrived. Hint: Create two semaphores, named aArrived and bArrived, and initialize them both to zero. aArrived indicates whether Thread A has arrived at the rendezvous, and bArrived likewise. Thread A statement a1; aArrived.up(); bArrived.down(); statement a2; Thread B statement b1; bArrived.up(); aArrived.down(); statement b2; semaphore aArrived=0; semaphore bArrived=0; Adapted from The Little Book of Semaphores.

13 Rendezvous – A less efficient solution This solution also works, although it is probably less efficient, since it might have to switch between A and B one time more than necessary. If A arrives first, it waits for B. When B arrives, it wakes A and might proceed immediately to its wait in which case it blocks, allowing A to reach its signal, after which both threads can proceed.. Thread A statement a1 bArrived.down()‏ aArrived.up()‏ statement a2 Thread B statement b1; bArrived.up(); aArrived.down(); statement b2; semaphore aArrived=0; semaphore bArrived=0; Adapted from The Little Book of Semaphores.

14 Rendezvous – How about? Thread A statement a1 bArrived.down()‏ aArrived.up()‏ statement a2 Thread B statement b1; aArrived.down(); bArrived.up(); statement b2; semaphore aArrived=0; semaphore bArrived=0; Adapted from The Little Book of Semaphores.

15 Barrier rendezvous(); criticalpoint(); Rendezvous solution does not work with more than two threads. Puzzle: Generalize the rendezvous solution. Every thread should run the following code: The synchronization requirement is that no thread executes critical point until after all threads have executed rendezvous. You can assume that there are n threads and that this value is stored in a variable, n, that is accessible from all threads. When the first n − 1 threads arrive they should block until the nth thread arrives, at which point all the threads may proceed. Adapted from The Little Book of Semaphores.

16 Barrier - Hint n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; count keeps track of how many threads have arrived. mutex provides exclusive access to count so that threads can increment it safely. barrier is locked (zero or negative) until all threads arrive; then it should be unlocked (1 or more). Adapted from The Little Book of Semaphores.

17 Barrier – Solution? n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex.down(); count = count + 1; mutex.up(); if (count == n) barrier.up(); else barrier.down(); Criticalpoint(); Since count is protected by a mutex, it counts the number of threads that pass. The first n−1 threads wait when they get to the barrier, which is initially locked. When the nth thread arrives, it unlocks the barrier. What is wrong with this solution? Adapted from The Little Book of Semaphores.

18 Barrier – Solution? n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex.down(); count = count + 1; mutex.up(); if (count == n) barrier.up(); else barrier.down(); Criticalpoint(); Imagine that n = 5 and that 4 threads are waiting at the barrier. The value of the semaphore is the number of threads in queue, negated, which is -4. When the 5th thread signals the barrier, one of the waiting threads is allowed to proceed, and the semaphore is incremented to -3. But then no one signals the semaphore again and none of the other threads can pass the barrier. Adapted from The Little Book of Semaphores.

19 Barrier – Solution n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex.down(); count = count + 1; mutex.up(); if (count == n) barrier.up(); else{ barrier.down(); barrier.up(); } Criticalpoint(); The only change is another signal after waiting at the barrier. Now as each thread passes, it signals the semaphore so that the next thread can pass. Adapted from The Little Book of Semaphores.

20 Barrier – Bad Solution n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex.down(); count = count + 1; if (count == n) barrier.up(); barrier.down(); barrier.up(); mutex.up(); Criticalpoint(); Imagine that the first thread enters the mutex and then blocks. Since the mutex is locked, no other threads can enter, so the condition, count==n, will never be true and no one will ever unlock. Adapted from The Little Book of Semaphores.