1. Why Events Are A Bad Idea (for high-concurrency servers) By Rob von Behren, Jeremy Condit and Eric Brewer

2. Arguments For Using Events Inexpensive synchronization Lower overhead for managing state Better scheduling and locality More flexible control flow

3. Arguments For Using Threads More natural for high-concurrency servers Threads can be improved to perform just as well as events Threads are more easily optimized by compilers

4. Events Versus Threads Lauer and Needham –Direct mapping EventsThreads Event handlersMonitors Events accepted by a handlerFunctions exported by a module SendMessage / AwaitReplyProcedure call, or fork/join SendReplyReturn from a procedure Waiting for messagesWaiting on condition variables

5. Events Versus Threads –Preservation of performance Need equally good implementations primitives –Use whichever is more natural

6. Problems with Threads Performance –High overhead –Context switches Restrictive Flow Control –Forces linear programming style Synchronization –Expensive (events get it for free?)

7. Problems with Threads State Management –Thread stack ineffective (overflow vs. wasted space) –Event programmers manage state by hand Scheduling –Virtual processor model prevents optimal scheduling decisions

8. Thread Benefits Flow Control –No need for “stack ripping” –Allows a more natural style Exception Handling –Simpler to do with threads –Easier to track live states (no need for garbage collection) Existing Systems –Threads used in existing event-driven systems –Used for error recovery, other complex areas

9. Improving Threads Improve thread packages Compiler support –Dynamic stack growth Stack size usually fixed –Can possibly overflow –Might waste space Allow compiler to determine the stack size Java Virtual Machine stack

10. Compiler support –Live state management Again need compiler help Pop temporary variables Frame can be popped for tail calls Reorder variables to allow dead variable to be freed Warn programmer if a lot of state is being held –Synchronization Warnings about data races Indicate which sections can run concurrently

11. Implementation User-level threads –Cannot preempt each other –Must yield –Each thread will run to completion Coroutines to minimize cost of context switching –Context switches become calls to this library

12. Implementation Asynchronous I/O –Cannot yield if blocking on I/O –Sounds like events –Poll indicates EVENTS that have happened to certain file descriptors Scheduling policies –Favor active connections –Favor new connections

13. Results Knot (Connections) 700 Mbit/s Haboob (Max) 500 Mbit/s –Becomes CPU limited –More context switches than Knot Knot (Accepts) in-between –More closely matches Haboob’s policy

14. Test Fairness Uses a small workload Ran Haboob using JIT –Knot was written in? Knot does not reallocate resources

15. Reasons You Might Need Threads For high-concurrency Natural flow control Easier exception handling Allows implementation of more complex systems