1 / 114

Mutual Exclusion

Mutual Exclusion. Mutual Exclusion. We will clarify our understanding of mutual exclusion We will also show you how to reason about various properties in an asynchronous concurrent setting. Mutual Exclusion. Formal problem definitions Solutions for 2 threads Solutions for n threads

alaura
Télécharger la présentation

Mutual Exclusion

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. Mutual Exclusion

  2. Mutual Exclusion • We will clarify our understanding of mutual exclusion • We will also show you how to reason about various properties in an asynchronous concurrent setting Art of Multiprocessor Programming

  3. Mutual Exclusion • Formal problem definitions • Solutions for 2 threads • Solutions for n threads • Fair solutions • Inherent costs Art of Multiprocessor Programming

  4. Warning • You will never use these protocols • Get over it • You are advised to understand them • The same issues show up everywhere • Except hidden and more complex Art of Multiprocessor Programming

  5. Why is Concurrent Programming so Hard? • Try preparing a seven-course banquet • By yourself • With one friend • With twenty-seven friends … • Before we can talk about programs • Need a language • Describing time and concurrency Art of Multiprocessor Programming

  6. time Time • “Absolute, true and mathematical time, of itself and from its own nature, flows equably without relation to anything external.” (I. Newton, 1689) • “Time is, like, Nature’s way of making sure that everything doesn’t happen all at once.” (Anonymous, circa 1968) Art of Multiprocessor Programming

  7. time Events • An eventa0 of thread A is • Instantaneous • No simultaneous events (break ties) a0 Art of Multiprocessor Programming

  8. time Threads • A threadA is (formally) a sequence a0,a1, ...of events • “Trace” model • Notation: a0a1 indicates order a1 a2 … a0 Art of Multiprocessor Programming

  9. Example Thread Events • Assign to shared variable • Assign to local variable • Invoke method • Return from method • Lots of other things … Art of Multiprocessor Programming

  10. Threads are State Machines a0 a3 Events are transitions a2 a1 Art of Multiprocessor Programming

  11. States • Thread State • Program counter • Local variables • System state • Object fields (shared variables) • Union of thread states Art of Multiprocessor Programming

  12. time Concurrency • Thread A Art of Multiprocessor Programming

  13. time time Concurrency • Thread A • Thread B Art of Multiprocessor Programming

  14. time Interleavings • Events of two or more threads • Interleaved • Not necessarily independent (why?) Art of Multiprocessor Programming

  15. time Intervals • An intervalA0 =(a0,a1) is • Time between events a0 and a1 a0 a1 A0 Art of Multiprocessor Programming

  16. a0 a1 A0 time Intervals may Overlap b0 b1 B0 Art of Multiprocessor Programming

  17. a0 a1 A0 time Intervals may be Disjoint b0 b1 B0 Art of Multiprocessor Programming

  18. a0 a1 A0 time Precedence Interval A0precedes interval B0 b0 b1 B0 Art of Multiprocessor Programming

  19. Precedence • Notation: A0  B0 • Formally, • End event of A0 before start event of B0 • Also called “happens before” or “precedes” Art of Multiprocessor Programming

  20. Precedence Ordering • Remark: A0  B0 is just like saying • 1066 AD  1492 AD, • Middle Ages  Renaissance, • Oh wait, • what about this week vs this month? Art of Multiprocessor Programming

  21. Precedence Ordering • Never true that AA • If ABthen not true that BA • If AB&BCthen AC • Funny thing: AB&BAmight both be false! Art of Multiprocessor Programming

  22. Partial Orders(review) • Irreflexive: • Never true that AA • Antisymmetric: • If ABthen not true that BA • Transitive: • If AB&BCthen AC Art of Multiprocessor Programming

  23. Total Orders(review) • Also • Irreflexive • Antisymmetric • Transitive • Except that for every distinct A, B, • Either ABorBA Art of Multiprocessor Programming

  24. Repeated Events while (mumble) { a0; a1; } k-th occurrence of event a0 a0k k-th occurrence of interval A0 =(a0,a1) A0k Art of Multiprocessor Programming

  25. Implementing a Counter public class Counter { private long value; public long getAndIncrement() { temp = value; value = temp + 1; return temp; } } Make these steps indivisible using locks Art of Multiprocessor Programming

  26. Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } Art of Multiprocessor Programming

  27. Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } acquire lock Art of Multiprocessor Programming

  28. Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } acquire lock release lock Art of Multiprocessor Programming

  29. Using Locks public class Counter { private long value; private Locklock; public long getAndIncrement() { lock.lock(); try { inttemp = value; value = value + 1; }finally{ lock.unlock(); } returntemp; }} Art of Multiprocessor Programming

  30. Using Locks public class Counter { private long value; private Lock lock; public long getAndIncrement() { lock.lock(); try { int temp = value; value = value + 1; } finally { lock.unlock(); } return temp; }} acquire Lock Art of Multiprocessor Programming

  31. Using Locks public class Counter { private long value; private Lock lock; public long getAndIncrement() { lock.lock(); try { int temp = value; value = value + 1; } finally { lock.unlock(); } return temp; }} Release lock (no matter what) Art of Multiprocessor Programming

  32. Critical section Using Locks public class Counter { private long value; private Lock lock; public long getAndIncrement() { lock.lock(); try { inttemp = value; value = value + 1; } finally { lock.unlock(); } return temp; }} Art of Multiprocessor Programming

  33. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution Art of Multiprocessor Programming

  34. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be thread j’s m-th critical section execution Art of Multiprocessor Programming

  35. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be j’s m-th execution • Then either • or Art of Multiprocessor Programming

  36. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be j’s m-th execution • Then either • or CSikCSjm Art of Multiprocessor Programming

  37. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be j’s m-th execution • Then either • or CSikCSjm CSjmCSik Art of Multiprocessor Programming

  38. Deadlock-Free • If some thread calls lock() • And never returns • Then other threads must complete lock() and unlock() calls infinitely often • System as a whole makes progress • Even if individuals starve Art of Multiprocessor Programming

  39. Starvation-Free • If some thread calls lock() • It will eventually return • Individual threads make progress Art of Multiprocessor Programming

  40. Two-Thread vs n -Thread Solutions • 2-thread solutions first • Illustrate most basic ideas • Fits on one slide • Then n-thread solutions Art of Multiprocessor Programming

  41. Two-Thread Conventions class … implements Lock { … // thread-local index, 0 or 1 publicvoid lock() { int i = ThreadID.get(); int j = 1 - i; … } } Art of Multiprocessor Programming

  42. Two-Thread Conventions class … implements Lock { … // thread-local index, 0 or 1 public void lock() { int i = ThreadID.get(); intj = 1 - i; … } } Henceforth: i is current thread, j is other thread Art of Multiprocessor Programming

  43. LockOne class LockOne implementsLock { private boolean[] flag = new boolean[2]; public voidlock() { flag[i] =true; while(flag[j]) {} }

  44. LockOne class LockOne implements Lock { private boolean[] flag = newboolean[2]; public void lock() { flag[i] = true; while (flag[j]) {} } Each thread has flag

  45. LockOne class LockOne implements Lock { private boolean[] flag = new boolean[2]; public void lock() { flag[i] =true; while (flag[j]) {} } Set my flag

  46. LockOne class LockOne implements Lock { private boolean[] flag = new boolean[2]; public void lock() { flag[i] = true; while(flag[j]) {} } Wait for other flag to become false

  47. LockOne SatisfiesMutual Exclusion • AssumeCSAjoverlapsCSBk • Consider each thread's last (j-th and k-th) read and write in the lock() method before entering • Derive a contradiction Art of Multiprocessor Programming

  48. From the Code • writeA(flag[A]=true)  readA(flag[B]==false) CSA • writeB(flag[B]=true)  readB(flag[A]==false)  CSB class LockOne implements Lock { … public voidlock() { flag[i] =true; while(flag[j]) {} } Art of Multiprocessor Programming

  49. From the Assumption • readA(flag[B]==false)  writeB(flag[B]=true) • readB(flag[A]==false)  writeA(flag[A]=true) Art of Multiprocessor Programming

  50. Combining • Assumptions: • readA(flag[B]==false)  writeB(flag[B]=true) • readB(flag[A]==false)  writeA(flag[A]=true) • From the code • writeA(flag[A]=true)  readA(flag[B]==false) • writeB(flag[B]=true)  readB(flag[A]==false) Art of Multiprocessor Programming

More Related