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

Semaphores

Ref: William StallingsG.Anuradha

Principle of a SemaphoreTwo 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-ConsumerImagine a chef cooking items and putting them onto a conveyor belt

10

Producer-ConsumerImagine a chef cooking items and putting them onto a conveyor belt

Now imagine many such chefs!

11



12



Now imagine a customer picking items off the conveyor belt

13



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 customers picking items off the conveyor belt!

15

Producer-Consumer

insertPtr

removePtr

Chef = ProducerCustomer = Consumer

16

Producer-Consumer

insertPtr

removePtr


17

Producer-Consumer

insertPtr

removePtr


18

Producer-Consumer

insertPtr

removePtr


19

Producer-Consumer

insertPtr

removePtr


20

Producer-Consumer

insertPtr

removePtr


21

Producer-Consumer

insertPtr

removePtr


22

Producer-Consumer

insertPtr

removePtr

BUFFER FULL: Producer must be blocked!


23

Producer-Consumer

insertPtrremovePtr


24

Producer-Consumer

insertPtr

removePtr


25

Producer-Consumer

insertPtr

removePtr


26

Producer-Consumer

insertPtr

removePtr


27

Producer-Consumer

insertPtr

removePtr


28

Producer-Consumer

insertPtr

removePtr


29

Producer-Consumer

insertPtr

removePtr


30

Producer-Consumer

insertPtr

removePtr

BUFFER EMPTY: Consumer must be blocked!


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 itemwait(s)append to queuen++if n = 1 then signal(delay)signal(s)

• Consumerwait(delay)do forever

wait(s)remove from queuen--m = nsignal(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;var max_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: integer beginbegin 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

Reader Writer

Reader OK No

Writer No No

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 declarationsprocedure 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…………………………

Documents

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