1. Condition Variables and Transactional Memory: Problem or Opportunity? Polina Dudnik and Michael Swift University of Wisconsin, Madison

2. Executive Summary Problem: thread synchronization in TM Goal: robust synchronization primitive State of the art: Retry/orelse Main point: Condition Variables [CVs] still relevant Our contributions: −TM-compatible condition variables −Implementation independent −Performance comparable to original CVs

3. Outline Lessons from the past New ideas for TM Transaction/Condition Variable Interactions Design of TM-safe Condition Variables Evaluation

4. What is the problem? How should threads coordinate? How should threads wait for an event or state change? How does this problem change with transactions?

5. On the Road to CVs Semaphores [Dijkstra ‘65] Condition Critical Regions (CCRs) [Hoare ‘72] ProducerConsumer region buffer when (count < n) { pool [in] = nextp; in = (in+l) % n; count++; } region buffer when (count > 0 ) { nextc = pool [out]; out = (out + l) % n; count--; }

6. Hoare on CCR I feel this proposal [condition critical regions] is not suitable for operating system implementation. My proposed method encourages the programmer to ignore the question of which of several outstanding requests for a resource should be granted. Sir Anthony Hoare [Belfast ‘71]

7. Limitations of CCR 1.Atomicity 2.Excessive Context Switching 3.Restrictive Scheduling

8. Solution: Condition Variables Condition variable = queue of waiters Associated lock maintains mutual exclusion Signaling a CV = hint that state has changed [Mesa semantics: Lampson ‘79] Multiple CVs provide prioritized wakeup

9. Problem Solved CCR Atomicity Concerns Performance Issues Restrictive Scheduling Condition Variables Monitors Precise Wakeup Explicit Signaling/Multiple CVs

10. CVs Limitations Nested monitor problem How about nested function calls? Or waiting on two event queues?  Retry/orelse solves these problems! void foo () { lock(A); foo_bar(); unlock(A); } void foo_bar() { lock(B); wait(); unlock(B); }

11. TM Synchronization Today Retry/orelse [Harris et al. 2005] ProducerConsumer void put (int value) { atomic { if (available) { retry; } contents = value; available = true; } int get() { atomic { if (!available) { retry; } available = false; return contents; }

12. Why not retry? Nesting Composability  Restrictive scheduling  Potentially poor scalability Other proposals have the same problems: —atomic CCRs [Harris 2003], atomic Wait [Smaragdakis 2007], X10 conditional atomic blocks [Charles 2005]  It is too early to give up on condition variables!

13. Outline Lessons from the past New ideas Transaction/Condition Variable Interactions Design of TM-safe Condition Variables Evaluation

14. TM Condition Variables Original condition variables int get() { lock(l); getters++; while (!available) { wait(cv, l); } getters--; available = false; unlock(l); return contents; }

15. TM Condition Variables Convert locks to transactions int get() { begin_tx; getters++; while (!available) { wait(cv); } getters--; available = false; end_tx; return contents; }

16. TM Condition Variables Wait outside the transaction int get() { begin_tx; getters++; while (!available) { end_tx; wait(cv); begin_tx; } getters--; available = false; end_tx; return contents; }

17. Lost Wakeup Waiting Thread begin_tx; read_state; prepare_wait(); end_tx; wait(); Signaling Thread begin_tx; update_state; signal(); end_tx;

18. TM Condition Variables Split wait 1.prepare wait within transaction 2.commit 3.complete wait 4.restart transaction int get() { begin_tx; getters++; while (!available) { prepare_wait(cv); end_tx; complete_wait(cv); begin_tx; } getters--; available = false; end_tx; return contents; }

19. TM Condition Variables What happens with concurrent signalers? int get() { begin_tx; getters++; while (!available) { prepare_wait(cv); end_tx; complete_wait(cv); begin_tx; } getters--; available = false; end_tx; return contents; }

20. Update-Signal Order Waiting Thread begin_tx; while (!state) { prepare_wait(); end_tx; wait(); begin_tx; } end_tx; Signaling Thread begin_tx; update_state; signal(); end_tx;

21. TM-CV Implementations Deferred SignalSpeculative Signal Requirement — Commit Actions to invoke signal Implications — Increased wakeup latency — Commit action overhead Requirements — Escape actions to signal — Robust conflict detection to prevent livelock Implications — Low-latency wakeup

22. Outline Lessons from the past New ideas for TM Transaction/Condition Variable Interactions Design of TM-safe Condition Variables Evaluation

23. Workloads libMicro – Stress-test of conditional synchronization FluidAnimate PARSEC – Many critical sections, few condition variables ops StreamCluster PARSEC – Few critical sections, few condition variable ops Platform: Solaris + GEMS/LogTM-SE, 16 threads

24. Evaluation Questions to answer: 1)Does it work? 2)How two versions compare in performance? 3)How does performance compare to locks?

25. Results

26. Evaluation Answers to questions: 1)Does it work? YES 2)How two versions compare in performance? Differ under stress 3)How does performance compare to locks? Comparable performace

27. Conclusions Condition Variables are still relevant with TM Two implementations of TM-CV Different requirements on TM system Performance difference subject to potential overlap Read the paper for: Implementation independence

28. QUESTIONS?

29. Backup Slides

30. Different Colors

31. Example CV usage void BeginWrite() { pthread_mutex_lock(mutex); while (NWriters == 1 || NReaders > 0){ ++WaitingWriters; pthread_cond_wait(CanWrite,mutex); --WaitingWriters; } NWriters = 1; pthread_mutex_unlock(mutex}; }

32. Lost Wakeup Waiting Thread BEGIN_TX while (!state) { prepare_wait() COMMIT_TX wait() BEGIN_TX } COMMIT_TX Signaling Thread BEGIN_TX update_state BEGIN_ESCAPE signal() END_ESCAPE COMMIT_TX