610 likes | 726 Views
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
E N D
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.
Binary Semaphore Can only take on values 0, 1
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.
Classical Synchronization problems • Producer consumer problem • Reader-writer problem • Barber shop • Dining philosopher
I. Producer-Consumer Imagine a chef cooking items and putting them onto a conveyor belt
Producer-Consumer Imagine a chef cooking items and putting them onto a conveyor belt Now imagine many such chefs!
Producer-Consumer Imagine a chef cooking items and putting them onto a conveyor belt Now imagine many such chefs!
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
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!
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!
Producer-Consumer Chef = Producer Customer = Consumer insertPtr removePtr
Producer-Consumer Chef = Producer Customer = Consumer insertPtr removePtr
Producer-Consumer Chef = Producer Customer = Consumer insertPtr removePtr
Producer-Consumer Chef = Producer Customer = Consumer insertPtr removePtr
Producer-Consumer Chef = Producer Customer = Consumer insertPtr removePtr
Producer-Consumer Chef = Producer Customer = Consumer insertPtr removePtr
Producer-Consumer Chef = Producer Customer = Consumer insertPtr removePtr
Producer-Consumer Chef = Producer Customer = Consumer BUFFER FULL: Producer must be blocked! insertPtr removePtr
Producer-Consumer Chef = Producer Customer = Consumer insertPtr removePtr
Producer-Consumer Chef = Producer Customer = Consumer removePtr insertPtr
Producer-Consumer Chef = Producer Customer = Consumer removePtr insertPtr
Producer-Consumer Chef = Producer Customer = Consumer removePtr insertPtr
Producer-Consumer Chef = Producer Customer = Consumer removePtr insertPtr
Producer-Consumer Chef = Producer Customer = Consumer removePtr insertPtr
Producer-Consumer Chef = Producer Customer = Consumer removePtr insertPtr
Producer-Consumer Chef = Producer Customer = Consumer BUFFER EMPTY: Consumer must be blocked! removePtr insertPtr
Producer Consumer problem Infinite buffer
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; 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 begin 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;
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
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
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) • InCorrectuse 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 ( ….) { … } … } }