1. Presenting: Why Events Are A “Bad” Idea ( for high-concurrency servers) Paper by: Behren, Condit and Brewer, 2003 Presented by: Rania Elnaggar 1/30/2008

2. 2Rania Elnaggar Agenda Background: What are we talking about? “Thread” of discussion – Related work Define the two models Countering criticism to threads Performance Control flow Synchronization State management Scheduling Strengths of threaded model Intrinsic properties Enabling mechanisms Implementation in Knot Conclusion & future directions

3. 1/30/2008 3Rania Elnaggar Background

4. 1/30/2008 4Rania Elnaggar “Thread” of discussion "Why Threads Are A Bad Idea (for most purposes)" by John Ousterhout, Talk Slides, Sun Microsystems Laboratories. September 1995. "SEDA: An Architecture for Well-Conditioned, Scalable Internet Services" Services" by Welsh, Culler, and Brewer, In Proceedings of the Eighteenth Symposium on Operating Systems Principles (SOSP-18), Banff, Canada, October, 2001. "On the Duality of Operating System Structures" by Lauer and Needham, in Proc. Second International Symposium on Operating Systems Principles, Oct 1978. Reprinted in SIGOPS Operating Systems Review, 13,2, Pages 3-19, April 1979. "Why Events Are A Bad Idea (for high-concurrency servers)" by Rob von Behren, Jeremy Condit and Eric Brewer, in proceedings HotOS IX, Kauai, Hawaii, May 2003.

5. 1/30/2008 5Rania Elnaggar Which side is better? Is it a dichotomy? Camp ThreadsCamp Events Events are WORSE! Threads are BAD!

6. 1/30/2008 6Rania Elnaggar Event-based model “Classic” definition: Small number of static processes Pre-defined, static communication mechanisms Address space is divided Synchronization and cooperation through message passing, therefore, known as message- passing model No “mutual” sharing of data Blocked I/O is complex to handle. Stack ripping.

7. 1/30/2008 7Rania Elnaggar The Pseudo-concurrent model Scheduler Handler 1 Handler 2 Handler 3 Handler 4

8. 1/30/2008 8Rania Elnaggar Thread-based model “Classic” definition: Large number of dynamic light-weight processes (i.e. threads) Classically procedure-oriented through fork and join Synchronization via shared data and interlocking. System resources encoded as global data structures and shared via locks Blocked I/O is a blocked thread. State saved in thread context.

9. 1/30/2008 9Rania Elnaggar The Quasi-concurrent model 123n Shared resources & address space

10. 1/30/2008 10Rania Elnaggar Beyond the flashy titles! What it says: Why threads are a “bad” idea. What it means: Artificial concurrency is bad when not justified by need. What it says: Why events are a “bad” idea. What it means: Events are not concurrent by definition and thus unsuitable for truly concurrent systems.

11. 1/30/2008 11Rania Elnaggar Apples and Oranges? Same LABEL, different FORMS Super Drink DecafDietLightLemonForte

12. 1/30/2008 12Rania Elnaggar Critique

13. 1/30/2008 13Rania Elnaggar Threads exhibit poor performance Artifact of poor threading implementation. Processes that are O(n) should be eliminated Did not address context switching overhead due to preemption!

14. 1/30/2008 14Rania Elnaggar Threads have restrictive control flow Threads lend themselves to “linear” control flow. If the control flow is complex, it will be error- prone and difficult to implement. Call/return, parallel calls and pipelines are easily implemented with threads Dynamic fan-in and fan-out is less graceful here but not used by highly concurrent servers.

15. 1/30/2008 15Rania Elnaggar Thread synchronization mechanisms are heavyweight “Cooperative scheduling” is free synchronization for events Not a property of events but rather of the “cooperative scheduling” Did not counter the argument! Need to introduce lighter-weight context switches.

16. 1/30/2008 16Rania Elnaggar Thread stacks are poorly fitted for live state mgmt Waste address space vs. risking stack overgrowth Introduce dynamic stack growth Automatic stack management has a lot of room for waste. Compiler optimization. It shows that those shortcomings can be overturned not that they don’t exist!

17. 1/30/2008 17Rania Elnaggar Threads prevent optimal scheduling decision Optimized scheduling decision can be easily made for event-driven systems Ex: shortest-completion time. Better scheduling for “locality” by running same-kind events in a row. Threads can be “scheduled” cooperatively to reap the same benefits.

18. 1/30/2008 18Rania Elnaggar Strengths

19. 1/30/2008 19Rania Elnaggar Intrinsic properties Control flow Easier to understand in threads Stack ripping in events and difficulty matching calls and returns. Exception handling and state lifetime Clean-up is easier in threaded systems Heap allocation in events together with error branching in control flow makes it difficult to clean up.

20. 1/30/2008 20Rania Elnaggar Enabling threads Compiler support to overcome performance impediments: Dynamic stack growth Live state management Synchronization

21. 1/30/2008 21Rania Elnaggar Knot – How does it scale?

22. 1/30/2008 22Rania Elnaggar Conclusion

23. 1/30/2008 23Rania Elnaggar What is the “best” answer? Threads Events It depends! Yet to be found! There is no “best” answer. It is only “an” answer!

24. 1/30/2008 24Rania Elnaggar Future Directions CMP is mainstream True concurrency is cheap Complex specialty architectures (ex: NUMA) will be less attractive Object Oriented No distinction between data and operations Encapsulated Entities – No locking nightmares! New languages and new compilers. Hybrid models? New models?

25. 1/30/2008 25Rania Elnaggar Thank you for staying tuned!