1 Cooperative Task Management without Manual Stack Management or Event-driven Programming is not the Opposite of Threaded Programming Atul Adya, Jon Howell, Marvin Theimer, William J. Bolosky, John R. Douceur Microsoft Research PRESENTED BY Zig Rosinski
24
Embed
1 Cooperative Task Management without Manual Stack Management or Event-driven Programming is not the Opposite of Threaded Programming Atul Adya, Jon Howell,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
11
Cooperative Task Management without Manual Stack Management
orEvent-driven Programming is not the Opposite of Threaded Programming
Atul Adya, Jon Howell, Marvin Theimer, William J. Bolosky, John R. Douceur
Microsoft Research
PRESENTED BY
Zig Rosinski
22
Notable References
“An Introduction to Programming with Threads”, Andrew D Birrell. (Week 1)
“On the Duality of Operating System Structures”, Lauer and Needham (Week 4)
“Why threads are a bad idea”, John Ousterhout (Week 4)
“SEDA: An Architecture for well-conditioned scalable internet services”, Matt Welsh, David Culler, and Eric Brewer. (Week 4)
33
Debate
The talk was given just before lunch and ‘stirred up a lively debate, which continued after the talk and all through the lunch’ http://static.userland.com/sh4/gems/lambda/OlegUSENIX2002.txt
44
Programming for I/O Concurrency
Multi-threaded programming– Difficult to handle race conditions,
deadlocks [Ousterhout96]
“Event-driven” model– Task explicitly yields control by
returning to the scheduler– Task runs serially between
yield points– E.g., X Windows event-loop style
Task A
Task B
I/O1
I/O2 done
I/O2
55
Unwieldy Code Structure appears in Event-Driven code
Can we get benefits of “event-driven” programming without contorting code structure?
}
F2() {
F1() {
}I/O
I/O done
}
F() {
}
66
Our Contributions
“multi-threaded”
“event-driven”
Task Management
Sta
ck M
ana
gem
ent
cooperative preemptive
auto
mat
icm
anua
l
“coroutines”
Separate out concerns of Separate out concerns of task and stack mgmttask and stack mgmt
Argue for not discarding Argue for not discarding automatic stack mgmtautomatic stack mgmt
Allow interactions Allow interactions between manual and between manual and automatic stack mgmt automatic stack mgmt code stylescode styles
Executing task has “lock” on shared stateExecuting task has “lock” on shared state
– Concurrency considered only at I/O yield points
– Task must re-validate state after resumingTask must re-validate state after resuming
May need to be done even with multi-threading, e.g., mutex May need to be done even with multi-threading, e.g., mutex released before calling high-latency opn [Birrell89]released before calling high-latency opn [Birrell89]
Allows I/O concurrency but not CPU concurrencyAllows I/O concurrency but not CPU concurrency
Cooperative Task ManagementTask A
Task BI/O1
I/O1 doneI/O2
99
Issues we’re NOT talking about
I/O ManagementI/O Management– Synchronous vs. asynchronousSynchronous vs. asynchronous– Concurrent I/O does not affect shared stateConcurrent I/O does not affect shared state
Conflict ManagementConflict Management– Pessimistic (mutexes/locks) vs. optimistic (abort/retry)Pessimistic (mutexes/locks) vs. optimistic (abort/retry)– Task mgmt: how often? Conflict mgmt: what to do?Task mgmt: how often? Conflict mgmt: what to do?
Data PartitioningData Partitioning– Monolithic vs. partitionedMonolithic vs. partitioned– Each partition independently sets task mgmt strategyEach partition independently sets task mgmt strategy