490dp Synchronous vs. Asynchronous Invocation

1
490dpSynchronous vs. AsynchronousInvocation

• Robert Grimm

2
Definitions by Merriam-Webster

• Synchronism
• chronological arrangement of historical events
  and personages so as to indicate coincidence or
  coexistence also a table showing such
  concurrences
• Asynchrony
• the quality or state of being asynchronous
  absence or lack of concurrence in time
• Invocation
• the act or process of petitioning for help or
  support

3
Whats It All About

• Control flow
• Model
• Usage
• Implementation

4
Synchronous Invocation

• Model
• Structured programming
• One process waits for anotherto complete a
  sub-task
• Usage
• Procedure / method call
• Implementation
• Call instruction, stack

5
Asynchronous Invocation

• Model
• Sending a message to another process
• Usage
• Raising an event to be processedby an event
  handler
• Implementation
• Event loop
• Queue of pending events

6
Adding Concurrency

• Process several tasks at the same time
• Synchronous invocation
• Threads
• Stack, registers
• Locks, condition variables
• Asynchronous invocation
• Just drop events for different tasksinto event
  loop

7
Advantages of Threads

• Sequential programming style
• Familiar to programmers
• Mature programming tools
• Multi-threaded debuggers
• Scalability with number of processors
• One thread per processor

8
Problems with Threads

• Elimination of race conditions
• Michael Burrows
• Eraser Savage et al., TOCS, (15)4391-411
• Performance tuning
• Lock contention

9
Advantages of Events

• Natural fit to some problem domains
• User interfaces
• Robustness under pressure
• Better scalability with load

10
Problems with Events

• Debugging
• No standard tools
• Performance
• Events do not scale over processors
• Event processing may still block
• Page faults, GC

11
The Best of Both Worlds

• Welsh et al.
• Spectrum from threads to pure events
• Components
• Queue of pending events
• Pool of one or more threads
• Taken together
• Task handler or animator

12
Design Patterns

• Wrap
• Pipeline
• Combine
• Replicate

13
Wrap

• Wrap a functional unit with an animator
• Simplest case
• One thread in pool
• No concurrency issues
• More complex
• Multiple threads in pool
• Higher throughput

14
Pipeline

• Split functional unit into two or more
• Units are cascaded
• Each unit has its own animator
• Limit number of threads for low-concurrency
  operations
• I/O operations
• Increase locality
• Process less code
• Touch less data

15
Combine

• Merge functional units and their animators
• Inverse of pipeline
• Limit overall number of threads

16
Replicate

• Copy functional unit and animator
• Improve parallelism
• Increased throughput
• Improve reliability
• Added resilience

17
Summary of Patterns

• Wrap to introduce load conditioning
• Pipeline to avoid wasting threads
• Pipeline for cache performance
• Replicate for fault tolerance
• Replicate to scale concurrency
• Combine to limit the number of threads

18
Coding for Spectrum

• Stateless functional units
• No concurrency control necessary
• Pass-by-value to avoid sharing
• Consistency
• Access
• Reclamation
• Alternative Release references
• Avoid fate sharing
• Improve fault tolerance
• Admission control at front
• Avoid internal congestions

19
Coding for Spectrum

• Stateless functional units
• No state shared between units
• Pass-by-value
• Crucial!
• Avoid fate sharing
• Part of replicate pattern
• Admission control at front
• Good practice

20
Break
21
The Case for Events

• Scale better than just threads
• Make execution state explicit
• Needed for check-pointing and migration
• Provide control over scheduling
• Useful for real-time applications

22
The Case for a Hybrid Scheme

• Enables better performance conditioning
• As discussed by Welsh et al.
• Provides isolation between applications
• Separate applications from each other
• Activation, termination
• Check-pointing, migration
• Separate core system from applications

23
Practical Considerations

• Functional units in Ninja
• Explicitly include task handlers
• Call specific event handlers
• Important goal for one.world
• Flexibility, ability to experiment
• Composition of functional units
• Break-down amongst animators

24
Functionality

• Events and event handlers
• Basic abstractions
• Components
• Building blocks for functional units
• Export and import event handlers
• Statically declared
• Dynamically linked
• Instantiated in environments
• Containers for stored tuples, components,other
  environments

25
Implementation of Event Passing

• Simple implementation
• Animator
• Queue and pool of one or more threads
• Mechanism
• Represented by concurrency domain
• One per environment

26
Simple Implementation

• Method invocation
• Default for event passing within environment
• Advantages
• Simple, cheap
• Problems
• Breaks for some interactions
• Infinite recursion
• Sender needs to wait for long time
• Thread is busy executing event handler

27
Animators

• Default for event passing across environments
• Forcibly linked through animator
• Advantages
• Handles all interactions
• Sender regains control immediately
• Drawback
• More expensive

28
Concurrency

• Remember Pool of one or more threads
• Declare components concurrency safe
• Protect access to internal state
• Least common denominator for environment
• No more than one thread if any component is not
  concurrency safe

29
Putting It All Together

• Environment determines
• Concurrency domain and animator
• Concurrency safe flag determines
• Number of threads
• Forcibly linked flag determines
• Simple implementation or animator