Atul Adya , Jon Howell, Marvin Theimer , William J. Bolosky , John R. Douceur Microsoft Research

1. Cooperative Task Management without Manual Stack Managementor, Event-driven Programming is Not the Opposite of Threaded Programming AtulAdya, Jon Howell, Marvin Theimer, William J. Bolosky, John R. Douceur Microsoft Research Presented by Poonam Singh CS 533 – Winter 2010

2. Outline • Task Management Serial, Cooperative, Preemptive • Stack Management Manual, Automatic • Importance of Sweet point Cooperative threading • Importance of adapters in switching from manual to automatic stackmanagement vice-versa.

3. Goal of Paper • Event-Driven Programming is not the opposite of Threaded Programming. • Cooperative Threading = Cooperative task management + automatic stack management. • Focuses on conflation of event-driven programming with multithreaded and shows how one can get the best of both worlds. • Importance of adapters in switching between manual stack management to automatic stack management and vice-versa.

4. Paper Organisation • First half of the paper talks about “How one can get the best of both world”. There arises the concept of “Conflation” which called as Sweet Spot. • Second half of the paper talks about how we find the glue between Manual Stack Management and Automatic Stack Management. • The Solution is Adapters!!!

5. Task ManagementSerial, Preemptive and co-operative Serial : • Divide the work, where each task encapsulates a control flow. • All tasks access some common shared area. • Task finishes and then yields control. • Advantage: No conflict access to shared area. Preemptive : (Multithreaded) • Opposite of serial. • High performance program. • Execution of tasks can interleave on uniprocessor or overlap on multiprocessor. • Control can be preempted from a particular task. Cooperative : (event-driven) • A compromise of serial and preemptive. • A task yields control at well defined points during execution, usually when task must wait for long running I/O.

6. Stack ManagementAutomatic and Manual • Manual Stack Management (event-driven) • Automatic Stack Management (Multithreaded ) Multithreaded Event-driven Automatic Stack management Manual Stack management Preemptive Task Management Cooperative Task Management ( non preemptive)

7. Importance of sweet point • Sweet Point = Cooperative task management preserving automatic stack management • Makes programming language structured. • Conflated Point

8. Reason why Task Management and Stack Management concept discussed in this paper ?????

9. Reason why Task Management and Stack Management concept discussed in this paper ????? Because Multithreaded programming and Event- driven programming styles conflates at these two concept. Author is finding the space that combines the advantage of both programming style (Sweet Spot).

10. Stack Management Automatic - Uses program stack provided by the procedural Language Code only with the compute only function CAInfoGetCAInfo(CAID caId) { CAInfocaInfo = LookupHashTable(caId); return caInfo; } • Automatic with I/O’s CAInfoGetCAInfoBlocking(CAID caId) { CAInfocaInfo = LookupHashTable(caId); if (caInfo != NULL) { // Found node in the hash table return caInfo; } caInfo = new CAInfo(); // DiskRead blocks waiting for // the disk I/O to complete. DiskRead(caId, caInfo); InsertHashTable(caId, CaInfo); return caInfo; }

11. Event Handler/ Scheduler Function in Manual Stack Management E1 . . initiate I/O register a Continuation stores a bundle state (data, E2) Terminate E2 Code after I/O completion . . Terminate

12. Stack ManagementManual Programming language procedures ripped into different Event Handlers. Example: void GetCAInfoHandler1(CAID caId, Continuation ∗callerCont) { // Return the result immediately if in cache CAInfo ∗caInfo = LookupHashTable(caId); if (caInfo != NULL) { // Call caller’s continuation withresult (∗callerCont−>function)(caInfo); return; } // Make buffer space for disk read caInfo = new CAInfo(); // Save return address & live variables Continuation ∗cont = new Continuation(&GetCAInfoHandler2, caId, caInfo, callerCont); // Send request EventHandle eh = InitAsyncDiskRead(caId, caInfo); // Schedule event handler to run on reply // by registering continuation RegisterContinuation(eh, cont); voidGetCAInfoHandler2(Continuation∗cont) { // Recover live variables CAID caId = (CAID) cont−>arg1; CAInfo ∗caInfo = (CAInfo∗) cont−>arg2; Continuation ∗callerCont = (Continuation∗) cont−>arg3; // Stash CAInfo object in hash InsertHashTable(caId, caInfo); // Now “return” results to original caller (∗callerCont−>function)(callerCont); }

13. Drawback of Manual Stack Management • Task Specific states are broken. • Control flow for a single conceptual task is also broken. • Magnifies the problem of stackripping: A call that did not yield yesterday may be changed tomorrow to yield for I/O, its signature changes to reflect the new structure. • More problems with I/O in functions having loops. If there are more I/O calls there are even more rips in the code. • Difficult to debug( Stack Unrecoverable). The programmer deconstructs the language stack, reconstructs it on the heap. • Program Becomes less readable. • Cumbersome code restructuring.

14. What people at Microsoft Think? • Two groups of developers – One supporting Manual Stack Management – The other strongly advocating the Automatic Stack Management • Pieces of Code exist written using both the styles of Stack Management • Need to find a glue!!

15. Solution • Hybrid Approach: - Enables both styles (automatic and manual) to coexist in the same code base using Adaptors to connect between them. - CooperativeTasks management can be achieved by scheduling multiple fibers on a single thread; at any given time, only one fiber is active. - Scheduler runs on a special fiber called MainFiberin both approaches. - Code with automatic stack management, that expects to block for I/O, always runs on a fiber other than MainFiber,when it blocks, it always yields control back to MainFiber, where scheduler selects the next task to schedule. - Compute only function, may run on any fiber. - Both types of stack management code are scheduled by the same scheduler(switching ).

16. Manual Calling Automatic and Automatic Calling Manual By Use of Adaptors Manual Automatic Manual Automatic

17. Working in both style using Adapters • In hybrid task of CFA(Continuation- to-Fiber adaptor) , task has been blocked for the I/O initiated by the code with automatic stack management while ensuring that event handler FetchCert2 does not block. • Later once I/O completes verifyFiber is resumed & then control return back to FiberStart. • In hybrid task of FCA(Fiber-to-Continuation adaptor), automatic stack management needs to block for I/O, but manual simply schedules the I/O and returns. • To reconcile, FCA used, that calls the manual code with a special continuation and relinquishes control to the MainFibercausing the adapter’s caller to remain blocked.

18. Implementation Of Cooperative Task Management • Farsite - Uses Windows fibers, Cooperative threading - A distributed, secure, serverless file system - Run overdesktops. • UCoM - Uses automatic stack management (exclusively). - A wireless phone application - Designed for Windows CE OS(client application that runs with UI and audio support)

19. Conclusions • Ongoing debate about “event-driven” vs “threaded” programming models got solved. • With adapters in place, each style of code is unaware of the other. • Choice of task management strategy(Cooperative task management) is fundamental but choice of stack management can be left to individual taste by using adapters. • Fiber execution looks like a continuation to the event-driven code, and the continuation scheduler like any other fiber to the procedure-oriented code.

20. References “Thanks to Jonathan Beareand AmitBhatfor providing me nice graphics ” “Thread-based vsevent-based implementation of a group communication service” S. Mishra and R. Yang.Thread-based “An Introduction to Programming with Threads” Andrew D Birrell “On the Duality of Operating System Structures” H. C. Lauer and R. M. Needham “Why threads are a bad idea (for most purposes)” John Ousterhout