Upload
gabriella-skinner
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
Condition Variables and Transactional Memory:
Problem or Opportunity?
Polina Dudnik and Michael SwiftUniversity of Wisconsin, Madison
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
Outline
• Lessons from the past• New ideas for TM
• Transaction/Condition Variable Interactions• Design of TM-safe Condition Variables
• Evaluation
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?
On the Road to CVs
Semaphores [Dijkstra ‘65] Condition Critical Regions (CCRs) [Hoare ‘72]
Producer Consumer
region bufferwhen (count < n) { pool [in] = nextp; in = (in+l) % n; count++;}
region buffer when (count > 0 ) { nextc = pool [out]; out = (out + l) % n; count--; }
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]
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
Problem Solved
CCR
Atomicity Concerns
Performance Issues
Restrictive Scheduling
Condition Variables
Monitors
Precise Wakeup
Explicit Signaling/Multiple CVs
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); }
TM Synchronization Today
Retry/orelse [Harris et al. 2005]Producer Consumer
void put (int value) { atomic { if (available) { retry; } contents = value; available = true; }}
int get() { atomic { if (!available) { retry; } available = false; return contents; }}
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!
Outline
• Lessons from the past• New ideas
• Transaction/Condition Variable Interactions• Design of TM-safe Condition Variables
• Evaluation
TM Condition Variables
Original condition variables
int get() { lock(l); getters++; while (!available) {
wait(cv, l); } getters--; available = false; unlock(l); return contents;}
TM Condition Variables
Convert locks to transactions
int get() { begin_tx; getters++; while (!available) { wait(cv); } getters--; available = false; end_tx; return contents;}
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;}
Lost Wakeup
Waiting Thread
begin_tx; read_state; prepare_wait(); end_tx;
wait();
Signaling Thread
begin_tx; update_state; signal();
end_tx;
TM Condition Variables
Split wait1. prepare wait within
transaction2. commit3. complete wait4. 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;}
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;}
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;
TM-CV Implementations
Deferred Signal Speculative 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
Outline
• Lessons from the past• New ideas for TM
• Transaction/Condition Variable Interactions• Design of TM-safe Condition Variables
• Evaluation
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
Evaluation
• Questions to answer:
1) Does it work?2) How two versions compare in performance?3) How does performance compare to locks?
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
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
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};
}