Semaphores Ref: William Stallings G.Anuradha

Principle of a Semaphore Two or more processes can cooperate by means of simple signals, such that a process can be forced to stop at a specified place until it has received a specific signal For signaling semaphores are used – For sending a signal semSignal (s) is used – For receiving a signal semWait(s) is used First defined by Dijkstra Semaphore is a variable – A semaphore may be initialized to a nonnegative integer value. – The semWait operation decrements the semaphore value. – The semSignal operation increments the semaphore value.

Definition of semaphore

Binary Semaphore Can only take on values 0, 1

Operations on Binary Semaphore

Types of Semaphores Binary semaphore:-takes value 0 and 1 Mutex:-similar to binary semaphore but the key difference is that the mutex is locked and unlocked by the same process Strong semaphore:- Process who is blocked the longest is released from queue first Weak semaphore:- Semaphore whose order is not specified.

Animation

Classical Synchronization problems Producer consumer problem Reader-writer problem Barber shop Dining philosopher

9 I. Producer-Consumer Imagine a chef cooking items and putting them onto a conveyor belt

10 Producer-Consumer Imagine a chef cooking items and putting them onto a conveyor belt Now imagine many such chefs!

11 Producer-Consumer Imagine a chef cooking items and putting them onto a conveyor belt Now imagine many such chefs!

12 Producer-Consumer Imagine a chef cooking items and putting them onto a conveyor belt Now imagine many such chefs! Now imagine a customer picking items off the conveyor belt

13 Producer-Consumer Imagine a chef cooking items and putting them onto a conveyor belt Now imagine many such chefs! Now imagine many such customers picking items off the conveyor belt!

14 Producer-Consumer Imagine a chef cooking items and putting them onto a conveyor belt Now imagine many such chefs! Now imagine many such customers picking items off the conveyor belt!

15 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

16 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

17 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

18 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

19 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

20 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

21 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

22 Producer-Consumer insertPtr removePtr BUFFER FULL: Producer must be blocked! Chef = Producer Customer = Consumer

23 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

24 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

25 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

26 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

27 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

28 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

29 Producer-Consumer insertPtr removePtr Chef = Producer Customer = Consumer

30 Producer-Consumer insertPtr removePtr BUFFER EMPTY: Consumer must be blocked! Chef = Producer Customer = Consumer

Producer Consumer problem Infinite buffer

Possible scenario

Correct solution

Finite circular buffer for the Producer/consumer problem

Summing up One process produces some type of data The other process consumes that data – Data stored in a shared buffer (infinite size) – Require mutual exclusion to access buffer Producer do forever produce item wait(s) append to queue n++ if n = 1 then signal(delay) signal(s) Consumer wait(delay) do forever wait(s) remove from queue n-- m = n signal(s) if m = 0 then wait(delay)

Barbershop Problem 3 barbers, each with a barber chair – Haircuts may take varying amounts of time Sofa can hold 4 customers, max of 20 in shop – Customers wait outside if necessary When a chair is empty: – Customer sitting longest on sofa is served – Customer standing the longest sits down After haircut, go to cashier for payment – Only one cash register – Algorithm has a separate cashier, but often barbers also take payment This is also a critical section

Fair Barbershop program barbershop2; varmax_capacity: semaphore (:=20); sofa: semaphore (:=4); barber_chair, coord: semaphore (:=3); mutex1, mutex2: semaphore (:=1); cust_ready, leave_b_chair, payment, receipt: semaphore (:=0) finished: array [1..50] of semaphore (:=0); count: integer; procedure customer; procedure barber;procedure cashier; var custnr: integer; var b_cust: integerbegin begin begin repeat wait (max_capacity ); repeat wait( payment ); enter shop; wait( cust_ready ); wait( coord ); wait( mutex1 ); wait( mutex2 ); accept payment; count := count + 1; dequeue1( b_cust ); signal( coord ); custnr := count; signal( mutex2 ); signal( receipt ); signal( mutex1 ); wait( coord ); forever wait( sofa ); cut hair;end; sit on sofa; signal( coord ); wait( barber_chair ); signal( finsihed[b_cust] ); get up from sofa; wait( leave_b_chair ); signal( sofa ); signal( barber_chair ); sit in barber chair;forever wait( mutex2 ); end; enqueue1( custnr ); signal( cust_ready ); signal( mutex2 ); wait( finished[custnr] ); leave barber chair; signal( leave_b_chair ); pay; signal( payment ); wait( receipt ); exit shop; signal( max_capacity ); end;

39 II. Reader-Writer Problem A reader: read data A writer: write data Rules: – Multiple readers may read the data simultaneously – Only one writer can write the data at any time – A reader and a writer cannot access data simultaneously Locking table: whether any two can be in the critical section simultaneously ReaderWriter Reader OKNo WriterNo

40 III. Dining Philosophers: an intellectual game 1

Problem Statement Five philosophers eat then think forever – They never sleep nor relieve themselves! – They do not behave altruistically They eat at a communal table – It has a single bowl of tangled spaghetti – Five plates each with a single fork to the left of their plate – To eat a philosopher must have two forks, their own and that of their neighbour’s to the right – If a philosopher is unable to eat they resume thinking

Ramifications Deadlock – All philosophers decide to eat at same time – They all pick up one fork – None of them can eat hence the system comes to a halt Starvation – Some philosophers think for such a short time and contrive to put their forks down in such a way that no other philosophers have the opportunity to pick up the two forks they require to eat

Deadlock - Pictorially

Starvation - Pictorially

Naïve Solution Unconstrained picking up and putting down of forks causes problems – So put down in the reverse order of picking up Manage the entry and exit of philosophers to the table by means of a Butler process that entry and exit is orderly Each fork is a process – Accessed either from left or right hand

Deadlocks Each philosopher has their left fork BUT Cannot get a right fork Butler did nothing – Needs to control access to table so that there is always one empty seat – Ensures one philosopher can eat

Butler Controls No more than 4 philosopher can sit at the table (enter) Once 4 philosophers seated then Butler only lets people exit (get down) from the table

Problems with Semaphores Incorrect usage of semaphores leads to timing errors Timing errors occur only if some particular execution sequence takes place.(rare) InCorrect use of semaphore operations – signal (mutex) …. wait (mutex) (multiple CS) – wait (mutex) … wait (mutex) (deadlock) – Omitting of wait (mutex) or signal (mutex) (or both)

Monitors A high-level abstraction (ADT) that provides a convenient and effective mechanism for process synchronization Only one process may be active within the monitor at a time Has one or more procedure, initialization sequence, local data Local data variables are accessible only by the monitor’s procedures and not by any external procedure monitor monitor-name { // shared variable declarations procedure P1 (…) { …. } … procedure Pn (…) {……} Initialization code ( ….) { … } … }

Schematic view of a Monitor

Condition Variables Synchronization is supported by the use of condition variables that are contained and accessible only within the monitor condition x, y; Two operations on a condition variable: – x.wait () – Suspends execution of the calling process on condition x. monitor is available for use by another process – x.signal () – resumes execution of some process suspended after a wait on the same condion. one of processes (if any) that invoked

Monitor with Condition Variables

Monitors for Producer consumer problem Monitor module used to control the buffer used to store and retrieve characters. Condition variables – Not full :- TRUE when there is room to add atleast one character to the buffer – Not empty :- TRUE when there is atleast one character in the buffer

Monitors for Producer consumer Bounded Buffer problem

Solution to Dining Philosophers monitor DP { enum { THINKING; HUNGRY, EATING) state [5] ; condition self [5];’/* hungry but is unable to obtain forks*/ /* A philosopher can set state[i]=eating only if state (i+4)%5 and (i+1)%5 are not eating */ void pickup (int i) { state[i] = HUNGRY; test(i); if (state[i] != EATING) self [i].wait; } void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); test((i + 1) % 5); }

Solution to Dining Philosophers (cont) void test (int i) { if ( (state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5] != EATING) ) { state[i] = EATING ; self[i].signal () ; } initialization_code() { for (int i = 0; i < 5; i++) state[i] = THINKING; }

Solution to Dining Philosophers (cont) Each philosopher I invokes the operations pickup() and putdown() in the following sequence: dp.pickup (i) EAT dp.putdown (i) No two neighbours eat simultaneously and no deadlocks will occur. But a philosopher can starve to death…………………………