Cooperative Task Management without Manual Stack Management or Event-driven Programming is not the Opposite of Threaded - PowerPoint PPT Presentation

kosey
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Cooperative Task Management without Manual Stack Management or Event-driven Programming is not the Opposite of Threaded PowerPoint Presentation
Download Presentation
Cooperative Task Management without Manual Stack Management or Event-driven Programming is not the Opposite of Threaded

play fullscreen
1 / 22
Download Presentation
Cooperative Task Management without Manual Stack Management or Event-driven Programming is not the Opposite of Threaded
156 Views
Download Presentation

Cooperative Task Management without Manual Stack Management or Event-driven Programming is not the Opposite of Threaded

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. 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

  2. Multi-threaded programming Difficult to handle race conditions,deadlocks [Ousterhout96] Programming for I/O Concurrency Task A • “Event-driven” model • Task explicitly yields control by returning to the scheduler • Task runs serially betweenyield points • E.g., X Windows event-loop style Task B I/O1 I/O2 I/O2 done

  3. F1() { F() { } F2() { } } Unwieldy Code Structure I/O I/O done } Can we get benefits of “event-driven” programming without contorting code structure?

  4. Our Contributions • 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 “multi- threaded” automatic Stack Management “coroutines” manual “event- driven” cooperative preemptive Task Management

  5. Overview • Cooperative Task Management • Stack Management • Automatic Stack Management (ASM) • Manual Stack Management (MSM) • Hybrid Code Interaction • Conclusions

  6. Cooperative Task Management Task A I/O1 • Executing task has “lock” on shared state • Concurrency considered only at I/O yield points • Task must re-validate state after resuming • 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 Task B I/O1 done I/O2

  7. Issues we’re NOT talking about • I/O Management • Synchronous vs. asynchronous • Concurrent I/O does not affect shared state • Conflict Management • 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

  8. 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

  9. Implement with user-level non-preemptive thread package, e.g., fibers in Windows Automatic Stack Mgmt (ASM) Info* GetInfo(ID id) { Info *info = LookupTable(id); return info; } When info is in memory Info* GetInfoBlocking(ID id) { Info *info = LookupTable(id); if (info != NULL) { return info; } SchedDiskReadAndYield(id, info); InsertTable(id, info); return info; } ASM code when info could be on disk

  10. Manual Stack Mgmt (MSM) Info* GetInfoBlocking(ID id) { void GetInfo1(ID id, Cont *c) { void GetInfo1(ID id) { void GetInfo2(Frame *f) { ID id = (ID) farg1; Info *info = (Info*) farg2; Info *info = LookupTable(id); if (info != NULL) { (cfunc)(cframe, info); return; return info; InsertTable(id, info); } Cont *c =(Cont*) farg3; SchedDiskReadAndYield(id, info); Frame *f = new Frame(id, info, c); Frame *f = new Frame(id, info); return info; (cfunc)(cframe, info); InsertTable(id, info); Cont *cont = new Cont(&GetInfo2, f); 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

  11. F1() I/O F2() MSM: Poor Software Structure One conceptual function split into multiple functions ASM Style MSM Style F() I/O done

  12. I/O I/O MSM: Poor Software Structure Loss of control structures, e.g., while loops ASM Style F() F1() F2() F3() MSM Style

  13. F1() I/O F2() MSM: Poor Software Structure Loss of local variables: stack frames on the heap ASM Style MSM Style Heap F() a = 17 Use a Frame I/O a: 17 … I/O done I/O done

  14. K1() H1() F1() F2() MSM: Poor Software Structure Loss of debugging stack: • Debugger not aware of stack frames on the heap • Some frames optimized way for convenience F1’s cont frame I/O H1’s cont frame I/O done K1’s cont frame MSM Style Heap

  15. F1() H1() Software Evolution F() Proc Call GetInfo1() H() Sched I/O GetInfo() Yield control I/O done Schedule I/O GetInfo2() I/O done H2() Proc Return F2() ASM Style MSM Style Stack Ripping:Software evolution exacerbates MSM code structure problems

  16. F1() H1() Detecting I/O Yields with MSM F() Proc Call GetInfo1(…, Cont * …) H() Sched I/O I/O done GetInfo(…) GetInfo2() H2() Proc Return F2() Signature change guarantees programmer aware of yielding

  17. Detecting I/O Yields with ASM F() H() Schedule I/O GetInfo() Yield control I/O done • Must verify changed semantics but no stack ripping • Static check allows same benefits as MSM

  18. Overview • Cooperative Task Management • Stack Management • Automatic Stack Management • Manual Stack Management • Hybrid Code Interaction • Conclusions

  19. MSM code calls ASM code F1() Does not expect continuation Expects to call GetInfo(id, contF2) and unroll stack GetInfo(Id id) Schedule I/O Yield control Process I/O Expects to be scheduled when GetInfo done I/O done Expects to return Info F2(Frame *f) Extract Info from f ASM Code MSM Code One stack (fiber) for MSM code One stack (fiber) per task for ASM code

  20. MSM code calls ASM code F1() M2A-Adapter() FiberStart(Id …) Start new fiber GetInfo(Id …) Schedule I/O Yield Process I/O F2 scheduled I/O done F2(Frame *f) Returns Info Schedules F2 with Info Extract Info from f MSM (MainFiber) ASM (Fiber 1) One code style unaware of other style

  21. Related Work • “Event-driven” to reduce concurrency bugs [Oust96] • Cooperative task management conflated with MSM • “Event-driven” model for performance • 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

  22. Separate concerns of task and stack management MSM leads to poor code structure Code evolution exacerbates problem ASM: natural code structure MSM and ASM code can co-exist For legacy code or different programmer preferences Conclusions “Coroutines” “Multi- threaded” Stack Management Automatic Manual “Event-driven” Cooperative Preemptive Task Management