1 / 22

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

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. Multi-threaded programming

kosey
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related