Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Operating Systems - Synchronization

3,186 views

Published on

From the Operating Systems course (CMPSCI 377) at UMass Amherst, Fall 2007.

Published in: Technology, Education

Operating Systems - Synchronization

  1. 1. Operating Systems CMPSCI 377 Synchronization Emery Berger University of Massachusetts Amherst UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
  2. 2. Synchronization Threads must ensure consistency  Else: race condition  (non-deterministic result) Requires synchronization operations  How to write concurrent code  How to implement synch. operations  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 2
  3. 3. Synchronization – Motivation “The too much milk problem”  Model of need to synchronize activities  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 3
  4. 4. Synchronization Terminology Mutual exclusion (“mutex”) – prevents multiple threads from entering Critical section – code only one thread can execute at a time Lock – mechanism for mutual exclusion Lock on entering critical section, accessing shared  data Unlock when complete  Wait if locked  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 4
  5. 5. Solving the Too Much Milk Problem Correctness properties  Only one person buys milk   Safety: “nothing bad happens” Someone buys milk if you need to   Progress: “something good eventually happens” First: use atomic loads & stores as building blocks  “Leave a note” (lock)  “Remove a note” (unlock)  “Don’t buy milk if there’s a note” (wait)  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 5
  6. 6. Too Much Milk: Solution 1 thread B thread A if (no milk && no note) if (no milk && no note) leave note leave note buy milk buy milk remove note remove note Does this work?much milk too  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 6
  7. 7. Too Much Milk: Solution 2 Idea: use labeled notes thread B thread A leave note A leave note B if (no note B) if (no note A) if (no milk) if (no milk) buy milk buy milk remove note A remove note B oops – no milk UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 7
  8. 8. Too Much Milk: Solution 3 Idea: wait for the right note thread B thread A leave note A leave note B while (note B) if (no note A) do nothing if (no milk) if (no milk) buy milk buy milk remove note B remove note A Exercise: verify this  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 8
  9. 9. Too Much Milk: Solution 3 Possibility 1: A first, then B thread B thread A leave note A leave note B while (note B) if (no note A) do nothing if (no milk) if (no milk) buy milk buy milk remove note B remove note A OK  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 9
  10. 10. Too Much Milk: Solution 3 Possibility 2: B first, then A thread B thread A leave note A leave note B while (note B) if (no note A) do nothing if (no milk) if (no milk) buy milk buy milk remove note B remove note A OK  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 10
  11. 11. Too Much Milk: Solution 3 Possibility 3: Interleaved – A waits & buys thread B thread A leave note A leave note B while (note B) if (no note A) do nothing if (no milk) if (no milk) buy milk buy milk remove note B remove note A OK  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 11
  12. 12. Too Much Milk: Solution 3 Possibility 4: Interleaved – A waits, B buys thread B thread A leave note A leave note B while (note B) if (no note A) do nothing if (no milk) if (no milk) buy milk buy milk remove note B remove note A OK  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 12
  13. 13. Too Much Milk: Solution 3 Solution 3: “Thread A waits for B, otherwise buys” Correct – preserves desired properties  Safety: we only buy one milk  Progress: we always buy milk  But…  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 13
  14. 14. Problems with this Solution Complicated  Difficult to convince ourselves that it works  Asymmetrical  Threads A & B are different  Adding more threads = different code for each thread  Poor utilization  Busy waiting – consumes CPU, no useful work  Possibly non-portable  Relies on atomicity of loads & stores  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 14
  15. 15. Language Support Synchronization complicated  Better way – provide language-level  support Higher-level approach  Hide gory details in runtime system  Increasingly high-level approaches:  Locks, Atomic Operations  Semaphores – generalized locks  Monitors – tie shared data to  synchronization UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 15
  16. 16. Locks Provide mutual exclusion to shared data  via two atomic routines acquire – wait for lock, then take it  release – unlock, wake up waiters  Rules:  Acquire lock before accessing shared data  Release lock afterwards  Lock initially released  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 16
  17. 17. Pthreads Syntax POSIX standard for C/C++  Mutual exclusion locks  Ensures only one thread in critical section  pthread_mutex_init (&l); … pthread_mutex_lock (&l); update data; /* critical section */ pthread_mutex_unlock (&l); UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 17
  18. 18. Pthreads API UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 18
  19. 19. Too Much Milk: Locks thread A thread B p_m_lock(&l) p_m_lock(&l) if (no milk) if (no milk) buy milk buy milk p_m_unlock(&l) p_m_unlock(&l) Clean, symmetric - but how do we implement it?  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 19
  20. 20. Implementing Locks Requires hardware support (in general)  Can build on atomic operations:  Load/Store  Disable interrupts  Uniprocessors only  Test & Set, Compare & Swap  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 20
  21. 21. Disabling Interrupts Prevent scheduler from switching threads  in middle of critical sections Ignores quantum expiration (timer interrupt)  No handling I/O operations  (Don’t make I/O calls in critical section!)  Why not implement as system call?  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 21
  22. 22. Disabling Interrupts Class Lock { private int value; private Queue q; Lock () { value = 0; q = empty; } public void release () { public void acquire () { disable interrupts; disable interrupts; if (q not empty) { if (value == BUSY) { thread t = q.pop(); add this thread to q; put t on ready queue; enable interrupts; } sleep(); value = FREE; } else { enable interrupts; value = BUSY; } } enable interrupts; } UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 22
  23. 23. Locks via Disabling Interrupts UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 23
  24. 24. Summary Communication between threads:  via shared variables Critical sections = regions of code that  modify or access shared variables Must be protected by synchronization  primitives that ensure mutual exclusion Loads & stores: tricky, error-prone  Solution: high-level primitives (e.g., locks)  UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 24
  25. 25. The End UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 25

×