Why%20Events%20Are%20a%20Bad%20Idea%20(for%20high%20concurrency%20servers) - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

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

Description:

Events based system requires effort by programmer ... Compile time analysis for data races. Challenging!! Implemented by TinyOS ... – PowerPoint PPT presentation

Number of Views:122
Avg rating:3.0/5.0
Slides: 15
Provided by: KarumbuN
Learn more at: http://web.cecs.pdx.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Why%20Events%20Are%20a%20Bad%20Idea%20(for%20high%20concurrency%20servers)


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

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)
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
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

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

6
Runtime Overhead
  • Criticism Threads dont 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!

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

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

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

10
Scheduling
  • Criticism Thread schedulers are too generic
  • Cant use application-specific information
  • Response
  • Use task program location for scheduling
  • Threads can do that too!
  • Lauder Needham duality paper

11
The Proof
  • User-level threads package
  • Intercept blocking system calls
  • No O(n) operations
  • Support gt 100K threads
  • Simple web server Knot
  • 700 lines of C code
  • Similar performance
  • Linear increase, then steady
  • Drop-off due to poll() overhead

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

13
The FutureCompiler-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

14
Conclusion
  • Performance
  • Ease of use
  • Compiler-runtime integration is key
About PowerShow.com