It looks like there are several good papers at this year’s Hot Topics in Operating Systems conference. One particularly interesting item, because it’s a topic that used to be discussed frequently on this site (it even has its own archive section) is von Behren, Condit and Brewer’s Why Events Are A Bad Idea. They raise many good points about the basic duality of thread-based and event-based systems, and about the various minor advantages of each.

One part of the paper which especially caught my attention was as follows. Haboob is a web server based on SEDA, while Knot is one developed by the authors.

Haboob’s maximum bandwidth of 500 Mbit/s is significantly lower than Knot’s, because Haboob becomes CPU limited at 512 clients. There are several possible reasons for this result. First, Haboob’s thread-pool-per-handler model requires context switches whenever events pass from one handler to another. This requirement causes Haboob to context switch 30,000 times per second when fully loaded – more than 6 times as frequently as Knot. Second, the proliferation of small modules in Haboob and SEDA (a natural outgrowth of the event programming model) creates a large number of module crossings and queuing operations.

Consider, if you will, a couple of statements from my own server-design article:

Note that, in this model, queuing of requests is done within stages, not between stages. This avoids the common silliness of constantly putting a request on a successor stage’s queue, then immediately invoking that successor stage and dequeuing the request again; I call that lots of queue activity – and locking – for nothing.

SEDA’s one significant flaw, in my opinion, is that it allocates a separate thread pool to each stage with only “background” reallocation of threads between stages in response to load. As a result, the #1 and #2 causes of context switches noted above are still very much present.

In fact, the latter comment is merely an echo of something I said almost a year ago:

Message passing systems are only immune to the context-switch problem if they run everything in a single thread, which is to say that they’ve traded away multiprocessor scalability for simplicity and single-thread performance. Message passing systems that use multiple threads – yes, even staged systems like SEDA – are just as prone to excessive context switches as any multithreaded program ever was.

It’s always nice to see one’s views on such a contentious subject validated. If I’m lucky, I might even get to thank the authors in person soon.