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]

Limitations of CCR

1. Atomicity2. Excessive Context Switching3. Restrictive Scheduling

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?

Results

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

QUESTIONS?

Backup Slides

Different Colors

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};

}

Lost Wakeup

Waiting Thread

BEGIN_TXwhile (!state) { prepare_wait() COMMIT_TX wait() BEGIN_TX}COMMIT_TX

Signaling Thread

BEGIN_TX update_state BEGIN_ESCAPE signal() END_ESCAPE

COMMIT_TX