1. CS 443 Advanced OS Fabián E. Bustamante, Spring 2005 Cooperative Task Management without Manual Stack Management or Event-driven programming is not the opposite of thread programming A. Adya, J. Howell, M. Theimer, W. Bolosky and J. Douceur Microsoft Research, Redmond Appears in USENIX ATC 2002 Presented by: Fabián E. Bustamante* * Some slides from Adya et al. presentation at Usenix ATC 2002

2. 2 Task Management Work of a program –A set of tasks, each encapsulating a control flow –All tasks access some common shared state Strategies –Preemptive task management Execution of tasks can interleave/overlap on uni/multiprocessors –Serial task management Each task runs to completion before starting next No conflict on shared state Problems if you want to exploit multiprocessor parallelism

3. 3 Cooperative Task Management Executing task has “lock” on shared state –Concurrency considered only at well defined points, commonly when needing to wait for I/O –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 Allows I/O concurrency but not CPU concurrency Need to wrap I/O calls to yield instead of blocking Task A Task B I/O 1 I/O 1 done I/O 2

4. 4 Stack Management Manual Stack Management (MSM) –Common approach to achieve cooperative task mgmt –Forces programmer to abandon basic programming language features Control flow for a single conceptual task * Task specific state are broken across several language procedures Automatic Stack Management (ASM) –Allows natural code structure

5. 5 Issues we’re NOT talking about I/O Management –Synchronous vs. asynchronous –Concurrent I/O does not affect shared state Conflict Management –Serial task mgmt – task is an atomic operation on shared state –Preemptive task mgmt – need synchronization primitives Pessimistic (mutexes/locks) vs. optimistic (abort/retry) –Cooperative task mgmt – large atomic operations – between yields Data Partitioning –Monolithic vs. partitioned –Each partition independently sets task mgmt strategy

6. 6 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” “event-driven” “sweet spot” Task Management Stack Management cooperativepreemptive automatic manual serial Conventional concurrent programming Traditional alternative This paper

7. 7 Stack Management – pros & cons Automatic stack management (ASM) –Each complete task as a single procedure –Procedures may call functions that block on I/O –While blocked, state is kept on procedure’ program stack Manual stack management (MSM) –Programmer must rip code for a task into event handlers that run to completion w/o blocking –To initiate I/O, event handler E 1 registers a continuation w/ scheduler –Continuation bundles State indicating where E 1 left off working on the task & Reference to another handler E 2 to work once I/O is completed

8. 8 Automatic to Manual Stack Mgmt From ASM in-memory to on-disk Info* GetInfoBlocking(ID id) { Info *info = LookupTable(id); } return info; if (info != NULL) { InsertTable(id, info); } Info* GetInfoBlocking(ID id) { Info *info = LookupTable(id); return info; } info = new Info(); DiskRead(id, info); return info; void *returnValue; Class Continuation { void (*function) (Continuation cont); void *arg1, *arg2, …’ } Function call when continuation is scheduled to run Return value set by I/O operation and passed to continuation Bundled up state To MSM …

9. 9 SchedDiskReadAndYield(id, info); SchedDiskRead(id, info, cont); void GetInfo1(ID id, Cont *c) {void GetInfo1(ID id) { Manual Stack Mgmt (MSM) Info* GetInfoBlocking(ID id) { if (info != NULL) { Info *info = LookupTable(id); SchedDiskReadAndYield(id, info); InsertTable(id, info); } return info; } void GetInfo2(Frame *f) { ID id = (ID) f  arg1; Info *info = (Info*) f  arg2; (c  func)(c  frame, info); InsertTable(id, info); return info; Frame *f = new Frame(id, info); } (c  func)(c  frame, info); return; Cont *c =(Cont*) f  arg3; Cont *cont = new Cont(&GetInfo2, f); Frame *f = new Frame(id, info, c); Stack frame manually maintained by programmer Task yields by unrolling stack to the scheduler Result returned to caller via a continuation function call

10. 10 Related Work “Event-driven” to reduce concurrency bugs (Ousterhout 96) –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 79] –Different equivalence than ASM and MSM –Cooperative task management not considered

11. 11 MSM: Poor Software Structure ASM Style F() Function scoping: 2+ language function for one conceptual F2() F1() MSM Style I/O I/O done

12. 12 I/O MSM: Poor Software Structure ASM Style MSM Style I/O F() F1() F2() F3() Control structures: Every basic block reachable from a continuation must be a separate function e.g., while loops

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

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

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

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

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

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

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

20. 20 Conclusions Separate concerns of task & stack mgmt 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 != programmer preferences “Multi- threaded” “Event-driven” “Coroutines” Task Management Stack Management cooperativepreemptive automatic manual serial