presenting: why events are a “bad” idea ( for high-concurrency servers) paper by: behren, condit...
TRANSCRIPT
Presenting: Why Events Are A “Bad” Idea(for high-concurrency servers)
Paper by: Behren, Condit and Brewer, 2003
Presented by: Rania Elnaggar1/30/2008
2Rania Elnaggar1/30/2008
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
3Rania Elnaggar1/30/2008
Background
4Rania Elnaggar1/30/2008
“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.
5Rania Elnaggar1/30/2008
Which side is better?Is it a dichotomy?
Camp ThreadsCamp Events
Events are WORSE!Threads are
BAD!
6Rania Elnaggar1/30/2008
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.
7Rania Elnaggar1/30/2008
The Pseudo-concurrent model
Scheduler
Handler 1
Handler 2
Handler 3
Handler 4
8Rania Elnaggar1/30/2008
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.
9Rania Elnaggar1/30/2008
The Quasi-concurrent model
1 2 3 n
Shared resources & address space
10Rania Elnaggar1/30/2008
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.
11Rania Elnaggar1/30/2008
Apples and Oranges?Same LABEL, different FORMS
SuperDrink
SuperDrink
SuperDrink
SuperDrink
SuperDrink
Decaf Diet Light Lemon Forte
12Rania Elnaggar1/30/2008
Critique
13Rania Elnaggar1/30/2008
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!
14Rania Elnaggar1/30/2008
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.
15Rania Elnaggar1/30/2008
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.
16Rania Elnaggar1/30/2008
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!
17Rania Elnaggar1/30/2008
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.
18Rania Elnaggar1/30/2008
Strengths
19Rania Elnaggar1/30/2008
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.
20Rania Elnaggar1/30/2008
Enabling threads
Compiler support to overcome performance impediments: Dynamic stack growth Live state management Synchronization
21Rania Elnaggar1/30/2008
Knot – How does it scale?
22Rania Elnaggar1/30/2008
Conclusion
23Rania Elnaggar1/30/2008
What is the “best” answer?
Threads Events It depends! Yet to be found! There is no “best”
answer. It is only “an” answer!
24Rania Elnaggar1/30/2008
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?
25Rania Elnaggar1/30/2008
Thank you for staying tuned!