CS 153 Design of Operating Systems Spring 18

Size: px

Start display at page:

Download "CS 153 Design of Operating Systems Spring 18"

Cecil Neal
6 years ago
Views:

1 CS 153 Design of Operating Systems Spring 18 Lectre 11: Semaphores Instrctor: Chengy Song Slide contribtions from Nael Ab-Ghazaleh, Harsha Madhyvasta and Zhiyn Qian

2 Last time Worked throgh software implementation of locks Good concrrency practice Ended p with Dekker and Peterson s algorithms» Work nder assmptions of atomic and in order memory system So, they do not work in practice Compiler reorders And memory system is not ordered Introdced hardware spport for synchronization Two flavors:» Atomic instrctions that read and pdate a variable E.g., test-and-set, xchange,» Disable interrpts CS 153 Lectre 11 Semaphores 2

3 Dekker s Algorithm Bool flag[2]l Int trn = 1; flag[0] = 1; while (flag[1]!= 0) { //while if(trn == 2) { flag[0] = 0; while (trn == 2); flag[0] = 1; //if critical section flag[0]=0; trn=2; otside of critical section flag[1] = 1; while (flag[0]!= 0) { //while if(trn == 1) { flag[1] = 0; while (trn == 1); flag[1] = 1; //if critical section flag[1]=0; trn=1; otside of critical section CS 153 Lectre 11 Semaphores 3

4 Peterson's Algorithm int trn = 1; bool try1 = false, try2 = false; while (tre) { try1 = tre; trn = 2; while (try2 && trn!= 1) ; critical section try1 = false; otside of critical section while (tre) { try2 = tre; trn = 1; while (try1 && trn!= 2) ; critical section try2 = false; otside of critical section This satisfies all the reqirements Here's why... CS 153 Lectre 11 Semaphores 4

5 Peterson's Algorithm: analysis int trn = 1; bool try1 = false, try2 = false; while (tre) { { try1 (trn == 1 trn == 2) 1 try1 = tre; { try1 (trn == 1 trn == 2) 2 trn = 2; { try1 (trn == 1 trn == 2) 3 while (try2 && trn!= 1) ; { try1 (trn == 1 try2 (try2 (yellow at 6 or at 7)) critical section 4 try1 = false; { try1 (trn == 1 trn == 2) otside of critical section while (tre) { { try2 (trn == 1 trn == 2) 5 try2 = tre; { try2 (trn == 1 trn == 2) 6 trn = 1; { try2 (trn == 1 trn == 2) 7 while (try1 && trn!= 2) ; { try2 (trn == 2 try1 (try1 (ble at 2 or at 3)) critical section 8 try2 = false; { try2 (trn == 1 trn == 2) otside of critical section (ble at 4) try1 (trn == 1 try2 (try2 (yellow at 6 or at 7)) (yellow at 8) try2 (trn == 2 try1 (try1 (ble at 2 or at 3))... (trn == 1 trn == 2) CS 153 Lectre 11 Semaphores 5

Using Test-And-Set Here is or lock implementation with test-and-set: strct lock { int held = 0; void acqire (lock) { while (test-and-set(&lock->held)); void release (lock) {

6 Using Test-And-Set Here is or lock implementation with test-and-set: strct lock { int held = 0; void acqire (lock) { while (test-and-set(&lock->held)); void release (lock) { lock->held = 0; When will the while retrn? What is the vale of held? Does it satisfy critical region reqirements? (mtex, progress, bonded wait, performance?) CS 153 Lectre 11 Semaphores 6

7 Disabling Interrpts Another implementation of acqire/release is to disable interrpts: strct lock { void acqire (lock) { disable interrpts; void release (lock) { enable interrpts; Note that there is no state associated with the lock Can two threads disable interrpts simltaneosly? CS 153 Lectre 11 Semaphores 7

8 On Disabling Interrpts Disabling interrpts blocks notification of external events that cold trigger a context switch (e.g., timer) In a real system, this is only available to the kernel Why? Disabling interrpts is insfficient on a mltiprocessor Back to atomic instrctions Like spinlocks, only want to disable interrpts to implement higher-level synchronization primitives Don t want interrpts disabled between acqire and release CS 153 Lectre 11 Semaphores 8

9 Smmarize Where We Are Goal: Use mtal exclsion to protect critical sections of code that access shared resorces Method: Use locks (spinlocks or disable interrpts) Problem: Critical sections can be long Spinlocks: Threads waiting to acqire lock spin in test-and-set loop Wastes CPU cycles Longer the CS, the longer the spin Greater the chance for lock holder to be interrpted Memory consistency model cases problems (ot of scope of this class) acqire(lock) Critical section release(lock) Disabling Interrpts: Shold not disable interrpts for long periods of time Can miss or delay important events (e.g., timer, I/O) CS 153 Lectre 11 Semaphores 9

10 Implementing Locks Block waiters, interrpts enabled in critical sections strct lock { int held = 0; qee Q; void acqire (lock) { Disable interrpts; if (lock->held) { pt crrent thread on lock Q; block crrent thread; lock->held = 1; Enable interrpts; void release (lock) { Disable interrpts; if (Q) remove and nblock a waiting thread; else lock->held = 0; Enable interrpts; acqire(lock) Interrpts Disabled Critical section Interrpts Enabled release(lock) Interrpts Disabled CS 153 Lectre 11 Semaphores 10

11 Higher-Level Synchronization Locks so far inefficient when critical sections are long Spinlocks inefficient Disabling interrpts can miss or delay important events Instead, we want synchronization mechanisms that Plan: Block waiters Leave interrpts enabled inside the critical section Look at two common high-level mechanisms» Semaphores: binary (mtex) and conting» Monitors: mtexes and condition variables Use them to solve common synchronization problems CS 153 Lectre 11 Semaphores 11

12 Semaphores Semaphores are an abstract data type that provide mtal exclsion to critical sections Block waiters, interrpts enabled within critical section Described by Dijkstra in THE system in 1968 Semaphores are integers that spport two operations: wait(semaphore): decrement, block ntil semaphore is open» Also P(), after the Dtch word for test, or down() signal(semaphore): increment, allow another thread to enter» Also V() after the Dtch word for increment, or p() That's it! No other operations not even jst reading its vale Semaphore safety property: the semaphore vale is always greater than or eqal to 0 CS 153 Lectre 11 Semaphores 12

13 Blocking in Semaphores Associated with each semaphore is a qee of waiting threads/processes When wait() is called by a thread: If semaphore is open, thread contines If semaphore is closed, thread blocks on qee Then signal() opens the semaphore: If a thread is waiting on the qee, the thread is nblocked If no threads are waiting on the qee, the signal is remembered for the next thread CS 153 Lectre 11 Semaphores 13

14 Semaphore Types Semaphores come in two types Mtex semaphore (or binary semaphore) Represents single access to a resorce Garantees mtal exclsion to a critical section Conting semaphore (or general semaphore) Mltiple threads pass the semaphore determined by cont» mtex has cont = 1, conting has cont = N Represents a resorce with many nits available or a resorce allowing some nsynchronized concrrent access (e.g., reading) CS 153 Lectre 11 Semaphores 14

15 Using Semaphores Use is similar to or locks, bt semantics are different strct Semaphore { int vale; Qee q; S; withdraw (accont, amont) { wait(s); balance = get_balance(accont); balance = balance amont; pt_balance(accont, balance); signal(s); retrn balance; Threads block critical section wait(s); balance = get_balance(accont); balance = balance amont; wait(s); wait(s); pt_balance(accont, balance); signal(s); signal(s); It is ndefined which thread rns after a signal signal(s); CS 153 Lectre 11 Semaphores 15

16 Beyond Mtal Exclsion We ve looked at a simple example for sing synchronization Mtal exclsion while accessing a bank accont We re going to se semaphores to look at more interesting examples Conting critical region Ordering threads Readers/Writers Prodcer consmer with bonded bffers More general examples CS 153 Lectre 11 Semaphores 16

17 Example Problem(s) Create a critical region where p to three threads (bt no more) may enter at a time Exploits the conting featre of semaphores Order operations across two threads; thread A exectes first, then thread B exectes Exploits the ability to initialize semaphores to different vales CS 153 Lectre 11 Semaphores 17

18 Readers/Writers Problem Readers/Writers Problem: An object is shared among several threads Some threads only read the object, others only write it We can allow mltiple readers bt only one writer» Let #r be the nmber of readers, #w be the nmber of writers» Safety: (#r 0) (0 #w 1) ((#r > 0) (#w = 0)) Use three variables int readcont nmber of threads reading object Semaphore mtex control access to readcont Semaphore w_or_r exclsive writing or reading CS 153 Lectre 11 Semaphores 18

19 Readers/Writers // nmber of readers int readcont = 0; // mtal exclsion to readcont Semaphore mtex = 1; // exclsive writer or reader Semaphore w_or_r = 1; writer { wait(w_or_r); // lock ot readers Write; signal(w_or_r); // p for grabs reader { wait(mtex); // lock readcont readcont += 1; // one more reader if (readcont == 1) wait(w_or_r); // synch w/ writers signal(mtex); // nlock readcont Read; wait(mtex); // lock readcont readcont -= 1; // one less reader if (readcont == 0) signal(w_or_r); // p for grabs signal(mtex); // nlock readcont CS 153 Lectre 11 Semaphores 19

20 Readers/Writers Notes w_or_r provides mtex between readers and writers Readers wait/signal when readcont goes from 0 to 1 or 1 to 0 If a writer is writing, where will readers be waiting? Once a writer exits, all readers can fall throgh Which reader gets to go first? Is it garanteed that all readers will fall throgh? If readers and writers are waiting, and a writer exits, who goes first? Why do readers se mtex? What if the signal is above if (readcont == 1)? If read in progress when writer arrives, when can writer get access? CS 153 Lectre 11 Semaphores 20

21 Bonded Bffer Problem: Set of bffers shared by prodcer and consmer threads Prodcer inserts jobs into the bffer set Consmer removes jobs from the bffer set Prodcer and consmer execte at different rates No serialization of one behind the other Tasks are independent (easier to think abot) The bffer set allows each to rn withot explicit handoff Data strctre shold not be corrpted De to race conditions Or prodcer writing when fll Or consmer deleting when empty CS 153 Lectre 11 Semaphores 21

22 Bonded Bffer (2) Semaphore mtex = 1; // mtal exclsion to shared set of bffers Semaphore empty = N; // cont of empty bffers (all empty to start) Semaphore fll = 0; // cont of fll bffers (none fll to start) prodcer { while (1) { Prodce new resorce; wait(empty); // wait for empty bffer wait(mtex); // lock bffer list Add resorce to an empty bffer; signal(mtex); // nlock bffer list signal(fll); // note a fll bffer consmer { while (1) { wait(fll); // wait for a fll bffer wait(mtex); // lock bffer list Remove resorce from a fll bffer; signal(mtex); // nlock bffer list signal(empty); // note an empty bffer Consme resorce; CS 153 Lectre 11 Semaphores 23

23 Bonded Bffer (3) Why need the mtex at all? The pattern of signal/wait on fll/empty is a common constrct often called an interlock Prodcer-Consmer and Bonded Bffer are classic examples of synchronization problems We will see and practice others CS 153 Lectre 11 Semaphores 24

24 Semaphore Smmary Semaphores can be sed to solve any of the traditional synchronization problems However, they have some drawbacks They are essentially shared global variables» Can potentially be accessed anywhere in program No connection between the semaphore and the data being controlled by the semaphore Used both for critical sections (mtal exclsion) and coordination (schedling)» Note that I had to se comments in the code to distingish No control or garantee of proper sage Sometimes hard to se and prone to bgs Another approach: Use programming langage spport CS 153 Lectre 11 Semaphores 25

CS 153 Design of Operating Systems Spring 18

CS 153 Design of Operating Systems Spring 18 Lectre 10: Lock Implementation Instrctor: Chengy Song Slide contribtions from Nael Ab-Ghazaleh, Harsha Madhyvasta and Zhiyn Qian Recap: Synchronization Race