1 / 27

Computer Systems Principles Synchronization

Computer Systems Principles Synchronization. Emery Berger and Mark Corner University of Massachusetts Amherst. Synchronization. Threads must ensure consistency Else: race condition (non-deterministic result) Requires synchronization operations How to write concurrent code

moke
Télécharger la présentation

Computer Systems Principles Synchronization

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. Computer Systems PrinciplesSynchronization Emery Berger and Mark Corner University of Massachusetts Amherst

  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

  3. Synchronization – Motivation • “The too much milk problem” • Model of need to synchronize activities

  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 entering critical section, accessing shared data • Unlock when complete • Wait if locked • Invariant • Something that must be true • when not holding lock

  5. Solving Too Much Milk • 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)

  6. thread A if (no milk && no note) leave note buy milk remove note Too Much Milk: Solution 1 thread B if (no milk && no note) leave note buy milk remove note too much milk • Does this work?

  7. thread A leave note A if (no note B) if (no milk) buy milk remove note A Too Much Milk: Solution 2 Idea: use labeled notes thread B leave note B if (no note A) if (no milk) buy milk remove note B oops – no milk

  8. thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A Too Much Milk: Solution 3 Idea: wait for the right note thread B leave note B if (no note A) if (no milk) buy milk remove note B • Quick Activity: does this work?

  9. thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A Too Much Milk: Solution 3 Possibility 1: A first, then B thread B leave note B if (no note A) if (no milk) buy milk remove note B • OK

  10. thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A Too Much Milk: Solution 3 Possibility 2: B first, then A thread B leave note B if (no note A) if (no milk) buy milk remove note B • OK

  11. thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A Too Much Milk: Solution 3 Possibility 3: Interleaved – A waits & buys thread B leave note B if (no note A) if (no milk) buy milk remove note B • OK

  12. thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A Too Much Milk: Solution 3 Possibility 4: Interleaved – A waits, B buys thread B leave note B if (no note A) if (no milk) buy milk remove note B • OK

  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…

  14. Problems with this Solution • Complicated • Difficult to convince ourselves that it works • Asymmetrical • Threads A & B are different • 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

  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

  16. Locks • Provide mutual exclusion to shared data • 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

  17. Locks and Queuing • Acquire: • if unlocked,go in;otherwise wait in line • Release: • Unlock & leave

  18. 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);

  19. Too Much Milk: Locks thread A thread B

  20. Too Much Milk: Locks • Clean, symmetric • How do we implement it? thread A p_m_lock(&l) if (no milk) buy milk p_m_unlock(&l) thread B p_m_lock(&l) if (no milk) buy milk p_m_unlock(&l)

  21. Implementing Locks • Requires hardware support (in general) • Can build on atomic operations: • Load/Store • Disable interrupts • Uniprocessors only • Test & Set, Compare & Swap

  22. 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?

  23. Class Lock { private int value; private Queue q; Lock () { value = 0; q = empty; } public void acquire () { disable interrupts; if (value == BUSY) { add this thread to q; enable interrupts; sleep(); } else { value = BUSY; } enable interrupts; } Disabling Interrupts public void release () { disable interrupts; if (q not empty) { thread t = q.pop(); put t on ready queue; } value = FREE; enable interrupts; }

  24. Locks via Disabling Interrupts

  25. Summary • Communication between threads • via shared variables • Critical sections • regions of code that 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)

  26. The End

  27. Pthreads API

More Related