1. Why Events Are a Bad Idea (for high concurrency servers)
CS533
Winter 2007
reference:

2. Load (concurrent tasks)
The Stage
Highly concurrent applications
Internet servers (Flash, Ninja, SEDA)
Operate “near the knee”
Avoid thrashing!
What makes concurrency hard?
Race conditions
Scalability (no O(n) operations)
Overload -Scheduling & resource contention
Ideal
Peak: some resource at max
Performance
Overload: some resource thrashing
Load (concurrent tasks)
reference:

3. The Debate Performance vs. Programmability Questions
Current threads pick one
Events somewhat better
Questions
Threads vs. Events?
Current Threads
Ideal
Ease of Programming
Current Events
Current Threads
Performance
reference:

4. Our Position Thread-event duality still holds
But threads are better anyway
More natural abstraction
Better fit with tools and hardware
Compiler-runtime integration is key
reference:

5. “Why Did we use Events” Recent arguments for events All true but…
Performance
Better live state management
Inexpensive synchronization
Better scheduling and locality
All true but…
No inherent problem with threads!
Thread implementations can be improved
reference:

6. Runtime Overhead
Criticism: Threads don’t perform well for high concurrency
Response
Avoid O(n) operations
Minimize context switch overhead
Simple scalability test
Slightly modified GNU Pth
Thread-per-task vs. single thread
Same performance!
reference:

7. Control Flow Criticism: Threads have restricted control flow Response
Programmers use simple patterns
Call / return
Parallel calls
Pipelines
Complicated patterns are unnatural
Hard to understand
Likely to cause bugs
reference:

8. Synchronization Criticism: Thread synchronization is heavyweight
Response
Basically non-preemption helps in events
Other factors
Starvation & fairness
Multiprocessors
Compiler support helps
reference:

9. Live State Management Criticism: Stacks are bad for live state
Response
Stack overflow vs. wasted space
Compiler Support
Dynamically link stack frames
Events based system requires effort by programmer
reference:

10. Scheduling Criticism: Thread schedulers are too generic Response
Can’t use application-specific information
Response
Use task & program location for scheduling
Threads can do that too!
Lauder Needham duality paper
reference:

11. The Proof User-level threads package Simple web server: Knot
Intercept blocking system calls
No O(n) operations
Support > 100K threads
Simple web server: Knot
700 lines of C code
Similar performance
Linear increase, then steady
Drop-off due to poll() overhead
100
200
300
400
500
600
700
800
900 1 4 16 64
256
1024
4096
16384
KnotC (Favor Connections)
KnotA (Favor Accept)
Haboob
Concurrent Clients
Mbits / second
reference:

12. Threads Also Have... More natural programming model
Control flow is more apparent
Exception handling is easier
State management is automatic
reference:

13. The Future: Compiler-Runtime Integration
Specific targets
Dynamic stack growth
Compiler analysis for amount of stack space needed for a function call
Live state management
Pop temporary variables
Reorder overlapping variables
Synchronization
Compile time analysis for data races
Challenging!!
Implemented by TinyOS
reference:

14. Conclusion Performance Ease of use Compiler-runtime integration is key
reference: