Lecture 3: Intro to Concurrent Processing using Semaphores

Similar documents
Semaphores INF4140. Lecture 3. 0 Book: Andrews - ch.04 ( ) INF4140 ( ) Semaphores Lecture 3 1 / 34

Semaphores. Derived Inference Rules. (R g>0) Q g (g 1) {R} V (g) {Q} R Q g (g+1) V (s), hs := 1; i

Semaphores. Mutual Exclusion. Inference Rules. Fairness: V may release a waiting process. Weakly fair, Strongly fair, or FIFO

Lecture 2: Intro to Concurrent Processing

Concept of a process

Process Synchronization. studykorner.org

Interprocess Communication By: Kaushik Vaghani

Lecture Topics. Announcements. Today: Concurrency (Stallings, chapter , 5.7) Next: Exam #1. Self-Study Exercise #5. Project #3 (due 9/28)

CSC501 Operating Systems Principles. Process Synchronization

Concurrency pros and cons. Concurrent Programming Problems. Linked list example. Linked list example. Mutual Exclusion. Concurrency is good for users

Process Synchronization

Lecture 2: Intro to Concurrent Processing. A Model of Concurrent Programming

Concurrency pros and cons. Concurrent Programming Problems. Mutual Exclusion. Concurrency is good for users

Process Management And Synchronization

Chapter 6: Process Synchronization

Semaphore Use In Synchronization

Semaphore. Originally called P() and V() wait (S) { while S <= 0 ; // no-op S--; } signal (S) { S++; }

Process Synchronization: Semaphores. CSSE 332 Operating Systems Rose-Hulman Institute of Technology

CSE Traditional Operating Systems deal with typical system software designed to be:

Process Synchronization

Operating Systems. Designed and Presented by Dr. Ayman Elshenawy Elsefy

Chapter 6: Process Synchronization

Chapter 5: Process Synchronization. Operating System Concepts Essentials 2 nd Edition

Chapter 6: Synchronization. Chapter 6: Synchronization. 6.1 Background. Part Three - Process Coordination. Consumer. Producer. 6.

Semaphores. Jinkyu Jeong Computer Systems Laboratory Sungkyunkwan University

Concurrent Processes Rab Nawaz Jadoon

Operating Systems ECE344

Process synchronization

Roadmap. Tevfik Ko!ar. CSC Operating Systems Fall Lecture - XI Deadlocks - II. Louisiana State University

Roadmap. Bounded-Buffer Problem. Classical Problems of Synchronization. Bounded Buffer 1 Semaphore Soln. Bounded Buffer 1 Semaphore Soln. Tevfik Ko!

CS3502 OPERATING SYSTEMS

Roadmap. Readers-Writers Problem. Readers-Writers Problem. Readers-Writers Problem (Cont.) Dining Philosophers Problem.

Silberschatz and Galvin Chapter 6

Chapter 6: Synchronization. Operating System Concepts 8 th Edition,

Opera&ng Systems ECE344

Chapter 6: Process Synchronization. Operating System Concepts 8 th Edition,

PROCESS SYNCHRONIZATION

Chapters 5 and 6 Concurrency

Concurrency. Chapter 5

CONCURRENT/DISTRIBUTED PROGRAMMING ILLUSTRATED USING THE DINING PHILOSOPHERS PROBLEM *

CS 361 Concurrent programming Drexel University Spring 2000 Lecture 14. The dining philosophers problem

5 Classical IPC Problems

OS Process Synchronization!

CS370 Operating Systems

Operating Systems Antonio Vivace revision 4 Licensed under GPLv3

CS370 Operating Systems

Chapter 2 Processes and Threads. Interprocess Communication Race Conditions

Explain briefly how starvation may occur in process scheduling. (2 marks)

Process Synchronization

Deadlocks. Frédéric Haziza Spring Department of Computer Systems Uppsala University

Operating Systems. Lecture 4 - Concurrency and Synchronization. Master of Computer Science PUF - Hồ Chí Minh 2016/2017

Semaphores. A semaphore is an object that consists of a. methods (e.g., functions): signal and wait. semaphore. method signal. counter.

Paralleland Distributed Programming. Concurrency

Lecture 11: More on invariants and textual reasoning - examples. K. V. S. Prasad Dept of Computer Science Chalmers University Friday 30 Sep 2016

Process Synchronization

Dealing with Issues for Interprocess Communication

PESIT Bangalore South Campus

CS370 Operating Systems

Semaphores. To avoid busy waiting: when a process has to wait, it will be put in a blocked queue of processes waiting for the same event

Semaphores. Semaphores. Semaphore s operations. Semaphores: observations

THE QUEEN S UNIVERSITY OF BELFAST

OPERATING SYSTEMS. Deadlocks

Process Synchronization

Deadlock and Monitors. CS439: Principles of Computer Systems September 24, 2018

Process Coordination

Chapter 7: Process Synchronization!

Introduction to Operating Systems

Operating Systems CMPSC 473. Synchronization February 26, Lecture 12 Instructor: Trent Jaeger

Process Synchronization. CISC3595, Spring 2015 Dr. Zhang

Sections 01 (11:30), 02 (16:00), 03 (8:30) Ashraf Aboulnaga & Borzoo Bonakdarpour

Deadlock and Monitors. CS439: Principles of Computer Systems February 7, 2018

Interprocess Communication and Synchronization

CSC Operating Systems Spring Lecture - XII Midterm Review. Tevfik Ko!ar. Louisiana State University. March 4 th, 2008.

Chapter 5: Process Synchronization. Operating System Concepts 9 th Edition

The dining philosophers problem. CS 361 Concurrent programming Drexel University Fall 2004 Lecture 13

Synchronization Basic Problem:

What is the Race Condition? And what is its solution? What is a critical section? And what is the critical section problem?

Semaphores (and Eventcounts) Otto J. Anshus University of {Tromsø, Oslo}

Roadmap. Tevfik Koşar. CSE 421/521 - Operating Systems Fall Lecture - X Deadlocks - I. University at Buffalo. Synchronization structures

Roadmap. Problems with Semaphores. Semaphores. Monitors. Monitor - Example. Tevfik Koşar. CSE 421/521 - Operating Systems Fall 2012

Concurrency: Deadlock and Starvation. Chapter 6

Lesson 6: Process Synchronization

Programming Languages

9/29/2014. CS341: Operating System Mid Semester Model Solution Uploaded Semaphore ADT: wait(), signal()

Concurrent Object Oriented Languages

Synchronization problems with semaphores

EECS 482 Introduction to Operating Systems

Semaphores. May 10, Mutual exclusion with shared variables is difficult (e.g. Dekker s solution).

Process Synchronization

There are 8 total numbered pages, 6 Questions. You have 60 minutes. Budget your time carefully!

5 Dining Philosophers. Template for Philosopher. Naive Solution. while (food available) /*pick up forks*/ eat; /*put down forks*/ think awhile;

Process Synchronization

Synchronization Principles

Semaphores. Otto J. Anshus University of {Tromsø, Oslo}

Synchronization. CS 475, Spring 2018 Concurrent & Distributed Systems

Background. Module 6: Process Synchronization. Bounded-Buffer (Cont.) Bounded-Buffer. Background

Contribution:javaMultithreading Multithreading Prof. Dr. Ralf Lämmel Universität Koblenz-Landau Software Languages Team

Synchronization Principles II

Deadlocks: Part I Prevention and Avoidance Yi Shi Fall 2017 Xi an Jiaotong University

Recall from Chapter 1 that a data race is a failure to correctly implement critical sections for non-atomic shared variable accesses.

Transcription:

Lecture 3: Intro to Concurrent Processing using Semaphores Semaphores; The Prucer-Consumer problem; The Dining Philosophers problem; The Readers-Writers Problem: Readers Preference Passing the Baton Ballhausen s Solution CA463D Lecture Notes (Martin Crane 2013) 1 Semaphores Dekker s algorithm solves the mutual exclusion problem on a shared memory machine with no support from the hardware or software. Semaphores are a higher level concept than atomic instructions. They are atomic actions & usually implemented at OS level A semaphore S is a non-negative integer variable that has exactly two operations defined for it: P(S) If S > 0 then S = S-1, otherwise susp the process. V(S) If there are processes susped on this semaphore wake one of them, else S = S + 1. An important point is that V(S), as it is currently defined, does not specify which of the susped processes to wake. CA463D Lecture Notes (Martin Crane 2013) 2 Crane 2013) 1

Semaphores (cont d): Semaphore Invariants The following invariants are true for semaphores: 0 = + # # where is the initial value of semaphore. CA463D Lecture Notes (Martin Crane 2013) 3 Semaphores (cont d): Mutual Exclusion With semaphores, guaranteeing mutual exclusion for N processes is trivial: # a semaphore to guarantee mutual exclusion among n processes sem mutex := 1 const N := 20 process p(i := 1 to N) Non_critical_Section P(mutex) # grab mutex semaphore Critical_Section V(mutex) # release mutex semaphore CA463D Lecture Notes (Martin Crane 2013) 4 Crane 2013) 2

Semaphores (cont d): Proof for Mutual Exclusion Theorem: Mutual exclusion is satisfied. Proof: Let # be the number of processes in their CS. We need to prove that # + = 1 is an invariant. Eqn 1 : # = # # (from the program structure) Eqn 2 : = 1 # + # (semaphore invariant) Eqn 3 : = 1 # (from (1) and (2)) + # = 1 (from (2) and (3)) QED CA463D Lecture Notes (Martin Crane 2013) 5 Theorem: Semaphores (cont d): Proof for Deadlock Avoidance The program cannot deadlock Proof: This would require all processes to be susped in their P(mutex) operations. Then = 0 and # = 0 since no process is in its CS. The critical section invariant just proven is : + # = 1 0 + 0 = 1 which is impossible. CA463D Lecture Notes (Martin Crane 2013) 6 Crane 2013) 3

Types of Semaphores Defined above is a general semaphore. A binary semaphore is a semaphore that can only take the values 0 and 1. Choice of which susped process to wake gives the following definitions: Blocked-set semaphore Awakens any one of the susped processes. Blocked-queue semaphore Susped processes are kept in FIFO & are awakened in order of suspension. This is the type implemented in SR. Busy-wait semaphore The value of the semaphore is tested in a busy wait loop, with the test being atomic. There may be interleavings between loop cycles. CA463D Lecture Notes (Martin Crane 2013) 7 Types of Semaphores: Proofs Theorem With busy-wait semaphores, starvation is possible. Proof: Consider the following execution sequence for 2 processes. 1. P1 executes P(mutex) and enters its critical section. 2. P2 executes P(mutex), finds mutex=0 and loops. 3. P1 finishes CS, executes V(mutex), loops back and executes P(mutex) and enters its CS. 4. P2 tests P(mutex), finds mutex=0, and loops. CA463D Lecture Notes (Martin Crane 2013) 8 Crane 2013) 4

Types of Semaphores: Proofs (cont d) 1. Theorem With blocked-queue semaphores, starvation is impossible. Proof: If P1 is blocked on mutex there will be at most N-2 processes ahead of P1 in the queue. Therefore after N-2 V(mutex) P1 will enter its critical section. 2. Theorem With blocked-set semaphores, starvation is possible for N 3. Proof: For 3 processes it is possible to construct an execution sequence such that there are always 2 processes blocked on a semaphore. V(mutex) is required to only wake one of them, so it could always ignore one and leave that process starved. CA463D Lecture Notes (Martin Crane 2013) 9 The Prucer-Consumer Problem This type of problem has two types of processes: Prucers Consumers processes that, due to some internal activity, pruce data to be sent to consumers. processes that on receipt of a data element consume data in some internal computation. Could join processes synchronously, such that data is only transmitted when prucer is ready to s it & consumer is ready to receive it. More flexible to connect prucers/consumers by a buffer (ie a queue) For an infinite buffer then the following invariants hold for the buffer: # 0 # = 0 + _ _ These invariants are exactly the same as the semaphore invariants with a semaphore called elements and an initial value 0. CA463D Lecture Notes (Martin Crane 2013) 10 Crane 2013) 5

The Prucer-Consumer Problem (cont d) var buffer [?]:int var in_pointer:int := 0, out_pointer:int := 0 sem elements := 0 process prucer buffer[in_pointer]:=pruce() in_pointer:=in_pointer+1 V(elements) process consumer var i:int P(elements) i:=buffer[out_pointer] out_pointer:=out_pointer+1 consume(i) Can be mified for real bounded circular buffers using another semaphore to count empty places in the buffer. CA463D Lecture Notes (Martin Crane 2013) 11 The Prucer-Consumer Problem (cont d) const N := 100 var buffer [N]:int var in_pointer:int := 0, out_pointer:int := 0 sem elements := 0 sem spaces := N process prucer var i:int i := pruce () P (spaces) buffer [in_pointer] := i in_pointer:=(in_pointer+1) m N V (elements) process consumer var i:int P (elements) i := buffer [out_pointer] out_pointer:=(out_pointer+1)m N V (spaces) consume (i) As an exercise prove the following: (i) No deadlock, (ii) No starvation & (iii) No data removal/apping from an empty/full buffer resp. CA463D Lecture Notes (Martin Crane 2013) 12 Crane 2013) 6

The Dining Philosophers Problem An institution hires five philosophers to solve a difficult problem. Each philosopher only engages in two activities - thinking & eating. Meals are taken in the diningroom which has a table set with five plates & five forks (or five bowls and five chopsticks). In the centre of the table is a bowl of spaghetti that is lessly replenished. The philosophers, not being very dextrous, require two forks to eat; Philosopher may only pick up the forks immediately to his left right. CA463D Lecture Notes (Martin Crane 2013) 13 Dining Philosophers (cont d) For this system to operate correctly it is required that: 1. A philosopher eats only if he has two forks. 2. No two philosophers can hold the same fork simultaneously. 3. There can be no deadlock. 4. There can be no individual starvation. 5. There must be efficient behaviour under the absence of contention. This problem is a generalisation of multiple processes accessing a set of shared resources; e.g. a network of computers accessing a bank of printers. CA463D Lecture Notes (Martin Crane 2013) 14 Crane 2013) 7

Dining Philosophers: First Attempted Solution Mel each fork as a semaphore. Then each philosopher must wait (execute a P operation) on both the left and right forks before eating. sem fork [5] := ([5] 1) # fork is array of semaphores all initialised to have value 1 process philosopher (i := 0 to 4) Think ( ) P(fork [i]) #grab fork[i] P(fork [(i+1) m 5] #grab rh fork Eat ( ) V(fork [i]) #release fork[i] V(fork [(i+1) m 5] #and rh fork CA463D Lecture Notes (Martin Crane 2013) 15 Dining Philosphers: Solution #1 This is called a symmetric solution since each task is identical. Symmetric solutions have advantages, e.g. for load-balancing. Can prove no fork is ever held by two philosophers since Eat() is the CS of each fork. If # is the number of philosophers holding fork i then we have + # = (ie either philosopher is holding the fork or sem is 1) Since a semaphore is non-negative then #. However, system can deadlock (i.e none can eat) when all philosophers pick up their left forks together; i.e. all processes execute P(fork[i]) before P(fork[(i+1)m 5] Two solutions: Make one philosopher take a right fork first (asymmetric solution); Only allow four philosophers into the room at any one time. CA463D Lecture Notes (Martin Crane 2013) 16 Crane 2013) 8

Dining Philosophers: Symmetric Solution This solution solves the deadlock problem. It is also symmetric (i.e. all processes execute the same piece of ce). sem Room := 4 sem fork [5] := ([5] 1) Process philosopher (i := 0 to 4) Think ( ) # thinking not a CS! P (Room) P(fork [i]) P(fork [(i+1) m 5] Eat ( ) # eating is the CS V(fork [i]) V(fork [(i+1) m 5] V (Room) CA463D Lecture Notes (Martin Crane 2013) 17 Dining Philosophers: Symmetric Solution (cont d) Proof of No Starvation Theorem Individual starvation cannot occur. Proof: For a process to starve it must be forever blocked on one of the three semaphores, Room, fork [i] or fork [(i+1) m 5]. a) Room semaphore If the semaphore is a blocked-queue semaphore then process i is blocked only if Room is 0 indefinitely. Requires other 4 philosophers to be blocked on their left forks, since if one of them can get two forks he will finish, put down the forks and signal Room (by V(Room)). So this case will follow from the fork[i] case. CA463D Lecture Notes (Martin Crane 2013) 18 Crane 2013) 9

Dining Philosophers: Symmetric Solution (cont d) Proof of No Starvation b) fork[i] semaphore If philosopher i is blocked on his left fork, then philosopher i-1 must be holding his right fork. Therefore he is eating or signalling he is finished with his left fork, So will eventually release his right fork (ie philosopher i s left fork). c) fork[i+1] m 5 semaphore If philosopher i is blocked on his right fork, this means that philosopher (i+1) has taken his left fork and never released it. Since eating and signalling cannot block, philosopher (i+1) must be waiting for his right fork, and so must all the others by induction: i+j, i. But with Room semaphore invariant only 4 can be in the room, So philosopher i cannot be blocked on his right fork. CA463D Lecture Notes (Martin Crane 2013) 19 The Readers-Writers Problem Two kinds of processes, readers and writers, share a DB. Readers execute transactions that examine the DB, writers execute transactions that examine and update the DB. Given that the database is initially consistent, then to ensure that it remains consistent, a writer process must have exclusive access. Any number of readers may concurrently examine the DB. Obviously, for a writer process, updating the DB is a CS that cannot be interleaved with any other process. CA463D Lecture Notes (Martin Crane 2013) 20 Crane 2013) 10

The Readers-Writers Problem (cont d) const M:int := 20, N:int := 5 var nr:int :=0 sem mutexr := 1 sem rw := 1 process reader (i:= 1 to M) P (mutexr) nr := nr + 1 if nr = 1 -> P (rw) fi V (mutexr) Read_Database ( ) P (mutexr) nr := nr - 1 if nr = 0 -> V (rw) fi V (mutexr) process writer(i:=1 to N) P (rw) Update_Database ( ) V (rw) Called the readers preference solution since if some reader is accessing the DB and a reader and a writer arrive at their entry protocols then the readers will always have preference over the writer process. CA463D Lecture Notes (Martin Crane 2013) 21 The Readers-Writers Problem (cont d) The Readers Preference Solution is not a fair one as it always gives readers precedence over writers So a continual stream of readers will block any writer process from updating the database. To make it fair need to use a split binary semaphore, i.e. several semaphores with the property that sum is 0 or 1. We also need to count the number of susped reader processes and susped writer processes. This technique is called passing the baton. CA463D Lecture Notes (Martin Crane 2013) 22 Crane 2013) 11

Readers/Writers: Passing the Baton const M:int := 20, N:int := 5 sem e:=1,r:=0,w:=0 #0 (e+r+w) 1 process reader (i:= 1 to M) P (e) if nw > 0 -> sr:= sr + 1; V(e); P(r) fi nr := nr + 1 if sr > 0 -> sr := sr - 1; V (r) [] sr = 0 -> V(e) fi Read_Database ( ) P (e) nr := nr - 1 if nr = 0 and sw > 0 -> sw := sw - 1; V (w) [] nr >0 or sw = 0 -> V(e) [] sr >0 and nw = 0 -> V(r) fi var nr:int :=0, nw:int := 0 var sr:int:=0, sw:int:=0 # no. of #susped readers & writers process writer (i:= 1 to N) P (e) if nr > 0 or nw > 0 -> sw:= sw + 1; V(e); P(w) fi nw := nw + 1 V (e) Update_Database ( ) P (e) nw := nw - 1 if sr >0 -> sr:= sr-1;v(r) [] sw >0 -> sw:= sw-1;v(w) [] sr =0 and sw =0 -> V(e) fi CA463D Lecture Notes (Martin Crane 2013) 23 Readers/Writers: Passing the Baton (cont d) Called Passing the Baton because of way signalling takes place (when a process is executing within a CS, it holds the baton ). When that process gets to an exit point from that CS, it passes the baton to some other process. If (more than)one process is waiting for a condition that is now true, baton is passed to one such process, randomly. If none is waiting, baton is passed to next one trying to enter the CS for the first time, i.e. trying P(e). CA463D Lecture Notes (Martin Crane 2013) 24 Crane 2013) 12

Passing the Baton (cont d): Scenarios Suppose a writer is in first. Any readers executing P(e) will be susped in a FIFO queue (sr:=sr+1) The writer will finish, execute P(e), decrement nw and eventually signal a susped (or maybe a new) reader who can then increment nr, awake the susped reader.. Note that the if in SR is non-deterministic (any of the else-if arms ([]) which apply can be executed non-deterministically) Suppose a reader is first to grab the entry semaphore. More readers can be let in as there are no sr s ([] sr=0->v(e)) A writer can come in but is immediately susped ping the signal from the last reader to exit after reading the database Note: the if at the of process reader is also non-deterministic CA463D Lecture Notes (Martin Crane 2013) 25 Readers-Writers: Ballhausen s Solution The idea behind this solution is one of efficiency: one reader takes up the same space as all readers reading together. A semaphore access is used for readers gaining entry to the DB, with a value initially equalling the total number of readers. Every time a reader accesses the DB, the value of access is decremented and when one leaves, it is incremented. When a writer wants to enter the DB it will occupy all space step by step by waiting for all old readers to leave and blocking entry to new ones. The writer uses a semaphore mutex to prevent deadlock between two writers trying to occupy half of the available space each. CA463D Lecture Notes (Martin Crane 2013) 26 Crane 2013) 13

Readers-Writers: Ballhausen s Solution (cont d) sem mutex = 1 sem access = m process reader (i = 1 to m) P(access) process writer (j = 1 to n) P(mutex) fa k = 1 to m -> P(access) af #... reading... V(access) # other operations #... writing... fa k = 1 to m -> V(access) af # other operations V(mutex) CA463D Lecture Notes (Martin Crane 2013) 27 Crane 2013) 14