1 / 14

Why Events Are a Bad Idea (for high concurrency servers)

Why Events Are a Bad Idea (for high concurrency servers). CS533 Winter 2007. 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)

jballance
Download Presentation

Why Events Are a Bad Idea (for high concurrency servers)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Why Events Are a Bad Idea (for high concurrency servers) CS533 Winter 2007 reference:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  2. 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: someresource thrashing Load (concurrent tasks) reference:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  3. The Debate • Performance vs. Programmability • Current threads pick one • Events somewhat better • Questions • Threads vs. Events? CurrentThreads Ideal Ease of Programming Current Events Current Threads Performance reference:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  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:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  5. “Why Did we use Events” • Recent arguments for events • 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:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  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:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  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:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  8. Synchronization • Criticism: Thread synchronization is heavyweight • Response • Basically non-preemption helps in events • Other factors • Starvation & fairness • Multiprocessors • Compiler support helps reference:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  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:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  10. Scheduling • Criticism: Thread schedulers are too generic • Can’t use application-specific information • Response • Use task & program location for scheduling • Threads can do that too! • Lauder Needham duality paper reference:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  11. 900 800 KnotC (Favor Connections) KnotA (Favor Accept) 700 Haboob Mbits / second 600 500 400 300 200 100 0 1 4 16 64 256 1024 4096 16384 Concurrent Clients The Proof • User-level threads package • 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 reference:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  12. Threads Also Have... • More natural programming model • Control flow is more apparent • Exception handling is easier • State management is automatic reference:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  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:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

  14. Conclusion • Performance • Ease of use Compiler-runtime integration is key reference:http://capriccio.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt

More Related