Cooperative Task Management with Manual Stack Management

Download Report

Transcript Cooperative Task Management with Manual Stack Management

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
1
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
I/O2
done
2
}
Unwieldy Code Structure
F1()
{
F()
{
}
I/O
I/O done
}
F2()
{
}
Can we get benefits of “event-driven” programming
without contorting code structure?
3
Our Contributions

automatic
“multithreaded”
manual

Separate out concerns of
task and stack mgmt
Argue for not discarding
automatic stack mgmt
Allow interactions
between manual and
automatic stack mgmt
code styles
Stack Management

“coroutines”
“eventdriven”
cooperative
preemptive
Task Management
4
Overview

Cooperative Task Management

Stack Management
–
–
Automatic Stack Management (ASM)
Manual Stack Management (MSM)

Hybrid Code Interaction

Conclusions
5
Cooperative Task Management
Task A
I/O1 done

Task B
I/O2
Executing task has “lock” on shared state
–
Concurrency considered only at I/O yield points
–
Task must re-validate state after resuming


I/O1
May need to be done even with multi-threading, e.g., mutex
released before calling high-latency opn [Birrell89]
Allows I/O concurrency but not CPU concurrency
6
Issues we’re NOT talking about

I/O Management
–
–

Conflict Management
–
–

Synchronous vs. asynchronous
Concurrent I/O does not affect shared state
Pessimistic (mutexes/locks) vs. optimistic (abort/retry)
Task mgmt: how often? Conflict mgmt: what to do?
Data Partitioning
–
–
Monolithic vs. partitioned
Each partition independently sets task mgmt strategy
7
Stack Management
How is the code structured:

Automatic Stack Management (ASM)
–

Allows natural code structure
Manual Stack Management (MSM)
–
–
Forces programmer to abandon basic programming
language features
Mistakenly conflated with cooperative task mgmt
8
Automatic Stack Mgmt (ASM)
When info is
in memory
ASM code when info
could be on disk
Info* GetInfo(ID id) {
Info *info = LookupTable(id);
return info;
}
Info* GetInfoBlocking(ID id) {
Info *info = LookupTable(id);
if (info != NULL) {
return info;
}
SchedDiskReadAndYield(id, info);
InsertTable(id, info);
return info;
}
Implement with user-level non-preemptive
thread package, e.g., fibers in Windows
9
Manual Stack Mgmt (MSM)
GetInfoBlocking(ID
{
void GetInfo1(ID id)
id, Cont
{Info* *c)
{
void id)
GetInfo2(Frame
*f) {
ID id = (ID) farg1;
Info *info = LookupTable(id);
if (info != NULL) { Info *info = (Info*) farg2;
(cfunc)(cframe, return
info); return;
info;
InsertTable(id, info);
}
Cont *c =(Cont*)
SchedDiskReadAndYield(id,
info); farg3;
Frame *f = new Frame(id,
info);c);
info,
return
info;
(cfunc)(cframe,
info);
InsertTable(id, f);
info);
Cont *cont = new Cont(&GetInfo2,
SchedDiskRead(id,
info,
cont);
return
info;
SchedDiskReadAndYield(id,
info); }
}
• Stack frame manually maintained by programmer
• Task yields by unrolling stack to the scheduler
• Result returned to caller via a continuation function call
10
MSM: Poor Software Structure
One conceptual function split into multiple functions
ASM
Style
F1()
MSM
Style
F()
I/O
I/O done
F2()
11
MSM: Poor Software Structure
Loss of control structures, e.g., while loops
ASM
Style
F()
F1()
F2()
I/O
I/O
F3()
MSM Style
12
MSM: Poor Software Structure
Loss of local variables: stack frames on the heap
ASM
Style
MSM
Style
F()
a = 17
F1()
I/O
I/O
I/O done
Use a
I/O done
Heap
Frame
a: 17
…
F2()
13
MSM: Poor Software Structure
Loss of debugging stack:
–
–
Debugger not aware of stack frames on the heap
Some frames optimized way for convenience
K1()
F1’s cont
frame
H1()
F1()
I/O
H1’s cont
frame
F2()
I/O done
K1’s cont
frame
MSM Style
Heap
14
Software Evolution
F() Proc Call
F1()
H1()
GetInfo1()
H()
Sched I/O
GetInfo() Schedule
I/O
Yield control
I/O
done
Proc
F2()
Return
ASM Style
I/O done
GetInfo2()
H2()
MSM Style
Stack Ripping: Software evolution exacerbates
MSM code structure problems
15
Detecting I/O Yields with MSM
F1()
F() Proc Call
H1()
GetInfo1(…, Cont * …)
H()
Sched I/O
GetInfo(…)
I/O done
GetInfo2()
H2()
Proc
Return
F2()
Signature change guarantees
programmer aware of yielding
16
Detecting I/O Yields with ASM
F()
H()
GetInfo()
Yield control
Schedule
I/O
I/O done
• Must verify changed semantics but no stack ripping
• Static check allows same benefits as MSM
17
Overview

Cooperative Task Management

Stack Management
–
–
Automatic Stack Management
Manual Stack Management

Hybrid Code Interaction

Conclusions
18
MSM code calls ASM code
F1()
Expects to call
GetInfo(id, contF2)
and unroll stack
Expects to be scheduled
when GetInfo done
F2(Frame *f)
Does not expect
continuation
GetInfo(Id id)
Yield control
Process I/O
Schedule I/O
I/O done
Expects to
return Info
Extract Info from f
MSM Code
ASM Code
One stack (fiber) for MSM code
One stack (fiber) per task for ASM code
19
MSM code calls ASM code
F1(
)
M2A-Adapter()
Start new fiber
FiberStart(Id …)
GetInfo(Id …) Schedule
F2
scheduled
F2(Frame *f)
Extract Info from f
MSM
(MainFiber)
I/O
Yield
Process I/O
Returns
Info
I/O done
Schedules
F2 with Info
ASM
(Fiber 1)
One code style unaware of other style
20
Related Work

“Event-driven” to reduce concurrency bugs [Oust96]
–

“Event-driven” model for performance
–
–

Cooperative task management conflated with MSM
Popular for web servers [Flash, Jaws, StagedServer, Seda]
Inter-stage: each task reads as in MSM
Equivalence of “procedure-oriented” and
“message-oriented” systems [Lauer+Needham]
–
–
Different equivalence than ASM and MSM
Cooperative task management not considered
21
 MSM
–
Code evolution exacerbates problem
 ASM:
 MSM
–
leads to poor code structure
natural code structure
Automatic
concerns of task and
stack management
Manual
 Separate
Stack Management
Conclusions
“Coroutines”
“Multithreaded”
“Event-driven”
and ASM code can co-exist
For legacy code or different
programmer preferences
Task Management
22