Cooperative Task Management without Manual Stack Management or, EventDriven Programming is Not the O

1
Cooperative Task Management without Manual Stack
Management or, Event-Driven Programming is Not
the Opposite of Threaded Programming

• A. Adya, J. Howell, M. Theimer, W. Bolosky, J.
  Douceur, Proceedings of 2002
• USENIX Annual Technical Conference, 2002
• Presented By Dutch T Meyer

2
Key Points

• Reframe the events/threads debate
• Introduce a new programming model
• Has the benefits of both paradigms
• Allows each side to work together

3
Separating Concurrency Concerns

• Lets take a break from the
• Threads Vs. Events battle.
• Task Management
• Stack Management

4
Task Management

• Preemtive Task Management
• Tasks can be stopped and resumed
• Serial Task Management
• Single task runs to completion
• Cooperative Task Management
• Only hand control to another task at a well
  defined point

5
Automatic Stack Management

• Think auto in C
• Stack is essentially transparent to programmer
• Compiler manages stack frames, function
  arguments, and local state
• Basic approach is simple and static

6
Manual Stack Management

• The structure of imparitive languages is based on
  a stack!
• How could you manage this yourself?

Some of stack frame must be maintained on the
heap!
7
Stack Ripping Invoking manual stack management

• Function scope is split with continuations
• Local state is explicitly managed on heap
• Program structure is modified
• Stack based debugging is impaired

8
Categorizing Multithreaded

• Automatic Stack Management
• Code retains linear flow, debugging, etc.
• Preemptive Task Management
• Code can yield at any point
• Locking required for shared resources

9
Categorizing Event-Driven

• Manual stack management
• Code structured as short lived handlers
• This usually requires extra work
• Cooperative task management
• no undeclared yield points
• Each handler runs to completion
• Shared state is automatically synchronized though
  event queue

10
Lessons in conflation

• Adya et al propose a new idea.

11
A Hybrid

• Use fibers as a mechanism for cooperative
  scheduling
• Not necessary to abandon automatic stack
  management
• Useful in situations where it is desirable to
  have events and threads side-by-side
• Programmer preference
• Software evolution

12
A High Level Example
Scheduler and dispatch/handlers
Potentially Blocking call
Fn1
I/O
Yield, provide continuation
I/O Ready
Fn1
Task Done
13
A High Level Example
Main Fiber Events and threads
Secondary Fiber Threaded Code that might block
Fn1
Fn1
14
The Main Fiber

• Acts like a scheduler
• Acts like an event handler
• Can dispatch events to event handlers
• Capable of transferring control to threaded
  components through an adaptor
• Transparency adapter looks like continuation

15
Secondary Fibers

• Used for Automatic Stack Management
• Used for potentially blocking calls
• Always yield to the main thread
• Requires asynchronous I/O
• Are effectively scheduled by main thread
• Capable of transferring control to event-driven
  code as it would any other procedure

16
Related work

• All our previous thread/events papers
• Coroutines
• M.E. Conway, Design of a separable
  transition-diagram compiler, Communications of
  the ACM, Vol. 6, No. 7, July 1963
• Farsite
• Atul Adya, William J. Bolosky, Miguel Castro, et
  al FARSITE Federated, Available, and Reliable
  Storage for an Incompletely Trusted Environment ,
  In the Proceedings of the 5th Symposium on
  Operating Systems Design and Implementation,
  Boston, MA, December 2002.

17
Discussion

• Discussion
• Discussion
• Discussion

18
Questions

• Many questions about the Pinning Pattern.
• What is with optimistic synchronization?
• Why is asynchronous IO required, and what is the
  cost?

19
Questions

• What is a continuation / would things be
  different with language support?
• What are Fibers / how do they yield?
• What is a tail call?

20
Questions?

• Is there any quantitative data to help answer
  this threads vs events debate?
• How much do we pay for the added complexity?
• Why is this project good/useful?

21
Fibers

• User level
• Cooperative scheduling
• Many-to-many mapping
• Many Caveats (eg Dont mix with exceptions)

Thread Context Switch Enter Kernel Mode Save
threads registers. Lock dispatcher Find next
thread Unlock dispatcher Swap out kernel state
Restore threads registers. Leave Kernel Mode
Fiber Context switch Save fiber state. Find next
fiber Swap out fiber state
22
Continuation

• A representation of function state
• In this context, a discretely separation around
  some point (eg, I/O)

Continuation
23
Closures and Coroutines

• Coroutines
• Subroutines that can return a value, take a
  break, then continue execution
• Have multiple points of entry and exit
• Closures
• Very generalized concept
• Functions that are bound in scope to another
  function

24
Continuation to Fiber adapter

• Used for events calling threads
• Creates a continuation for itself, calls the
  threaded function on a secondary fiber
• The adapters continuation calls the events
  (caller) continuation

Threaded code on secondary fiber
Event
CFA
25
Fiber to Continuation Adapter

• Used for connecting thread model to event
  model
• Leaves adapters caller blocked on the secondary
  fiber, yield to main fiber
• Registers a continuation with the main fiber

Threaded code on secondary fiber
FCA
Event