Why Events Are A Bad Idea (for high-concurrency servers)

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

Event-based programming has been highly touted in recent years as the best way to write highly concurrent applications. Having worked on several of these systems, we now believe this approach to be a mistake. Specifically, we believe that threads can achieve all of the strengths of events, including support for high concurrency, low overhead, and a simple concurrency model. Moreover, we argue that threads allow a simpler and more natural programming style.

The authors take the example of a web server to show that with compiler support for improved threads, they can achieve as good or better performance than event-based applications in high concurrency context.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Paper title a bit misleading

Their test program uses async I/O and a coroutine library; this still sounds more like 'events' than 'threads' to me. I think they're making too much of a small semantic distinction, and I'm a bit suspicious of their test methodology. (See the SEDA response to this paper and others at http://www.eecs.harvard.edu/~mdw/proj/seda/)

What semantic distinction

Do you have a more specific URL for the SEDA response, or is it on this page itself?
Keeping aside the benchmarks, the paper proposes that:
- Threads and events are equivalent (considering SEDA as a 'good' example of events)
- High-concurrency applications are easier to program with threads
- In these applications the extra flexibility of events is unnecessary

Considering this, I don't think that the fact they use a coroutine library and async I/O to implement threads is relevant.

Cognitive factor?

The duality of events and threads is both a folks theorem and a recurring theme of many papers, so I guess there is nothing especially controversial in this part of the statement (see also previous occurrence of OP on LtU).

The remaining part, "that threads allow a simpler and more natural programming style", is not easily verifyable in scope of computer science, it has more to do with social/biological sciences, and maybe a bit of statistics.

1. Regarding equivalency of

1. Regarding equivalency of threads and events: I agree.

2. Regarding ease of programming: I think it's obvious that writing sequential code is conceptually easier than writing in event-driven style. However, what's not easier is finding all the concurrency bugs in such threaded programs. Without a proper concurrency model to prevent such bugs, event-loops ala E or Erlang are *safer*, which I would think is a more significant indication of "ease" than how the code reads at first glance.

3. Regarding extra flexibility: contradiction; if threads and events are equivalent, then there is no "extra" flexibility available with events.

The paper mentions code

The paper mentions code analysis as a response to concurrency bugs in the threaded approach.

Compile-time analysis can reduce the occurrence of bugs by warning the programmer about data races. Although static detection of race conditions is challenging, there has been recent progress due to compiler improvements and tractable whole-program analyses

You may be right in regards to the added flexibility of events. From the paper I got the idea that some patterns are not suited to threads. The examples given are multicast and event handlers, although I can think of how to use threads for that.

I'd love a compile-time

I'd love a compile-time analysis to solve concurrency problems. But until we have it, we must conclude that event-loops are safer for the time being. So it seems the authors have actually proven the contrary of their abstract. :-)