1 / 60

Semaphores

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

gabriellej
Télécharger la présentation

Semaphores

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Semaphores Ref: William Stallings G.Anuradha

  2. 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.

  3. Definition of semaphore

  4. Binary Semaphore Can only take on values 0, 1

  5. Operations on Binary Semaphore

  6. 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.

  7. Animation

  8. 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 Chef = Producer Customer = Consumer insertPtr removePtr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  31. Producer Consumer problem Infinite buffer

  32. Possible scenario

  33. Correct solution

  34. Finite circular buffer for the Producer/consumer problem

  35. 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)

  36. 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

  37. 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;

  38. 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

  39. III. Dining Philosophers: an intellectual game 1

  40. 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

  41. 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

  42. Deadlock - Pictorially

  43. Starvation - Pictorially

  44. 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

  45. 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

  46. 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

  47. 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)

  48. 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 ( ….) { … } … } }

  49. Schematic view of a Monitor

More Related