4 ms·

Why Events Are a Bad Idea (for high-concurrency servers) (2003) [pdf]

72 points by relyio 9y ago

mjevans 9y ago
Modern processors are much faster than the outlying memory and persistent storage devices. They and compilers in combination are relatively good at optimizing for predictable patterns of using sequential blocks of the outlying memory. Context switches between tasks are expensive, because the state of the processor must be (at least partially) serialized and stored as well as the loss of the implicit context of the caches. Thus it makes /far/ more sense to have a number of threads (dependent on the hardware capacity and how readily the problem can be divided to independent or very loosely coupled tasks) which poll message queues than it does to have a completely independent thread for every event. Languages based around message passing are thus the obvious choice for this type of programming.
- eggie5 9y ago
  What modern server is this describing? "a number of threads ... which poll message queues..." and what is this describing? "...a completely independent thread for every event." "Languages based around message passing are thus the obvious choice for this type of programming." Ruby? Obj-c?
  - mjevans 9y ago
    The two languages that come to /my/ mind are Erlang and Go. Other programmers might have different choices. There's no reason you couldn't use a language that has threads to implement the N threads with event queues model, or something similar for that language if it has shared memory. If the language of choice lacks it you might be able to use a similar multi-process (externally) load-balanced model.
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]
  - mcguire 9y ago
    Pony. (https://www.ponylang.org https://www.ponylang.org) Actor-based programming model, where actors are Erlang-ish very lightweight green threads, running on a hardware thread per processor. Communicating by fast message passing.
- buzzybee 9y ago
  When the paper was written, the jury was still definitely out on good concurrency practices for applications: the computing world(apart from mainframes, which of course had learned every lesson 30 years earlier, but nobody paid much attention to) had only relatively recently exited the era where one might ordinarily synchronize your co-processing units at the instruction level, with hand-tuned assembly, just like any other piece of external hardware. Cooperative, event-based programming is familiar to this style. Asynchronous primitives backed by hardware scheduling were the "new kid" for a lot of programmers. So, like with every technology, there was some exuberance and overuse of a novel formalism which shows up in this paper: "scales to 100,000 threads", it proclaims. Not much later, interest in "green threading" and "lightweight concurrency" grew as a way to get some of the architectural benefits of being asynchronous while mitigating waste from large numbers of threads, and consensus shifted towards mixing the approaches, which seems to have converged on the few-threads, message-queue-per-thread approach.
metalliqaz 9y ago
Modern version of "considered harmful."
EGreg 9y ago
A few years later, Igor Sysoev will make NGinX which will blow Apache away in speed, and Apache 2 will adopt the paradigm.
- SwellJoe 9y ago
  There were many fast(er than Apache) web servers before nginx, many using various concurrency models, including the one used by nginx.
geezerjay 9y ago
here's a link to a related discussion on HN entitled Why Threads are a Bad Idea (for most purposes) (1995)" https://news.ycombinator.com/item?id=14547063 https://news.ycombinator.com/item?id=14547063
CodeWriter23 9y ago
Threads vs. events is a false dichotomy to me. Currently writing an event-driven finite state machine dispatcher that fires up threaded processes to perform long-running tasks that do not modify state. The FSM brings order and structure to chaotic event interactions, while threading enables full utilization of CPU cores. All the better to drain your battery, lol. Seriously though, I made this choice to balance reliability with responsivenes. Choose the right tool for the job.
- bullen 9y ago
  I agree that they are not contradictory but rather complementary: https://github.com/tinspin/rupy https://github.com/tinspin/rupy My web server uses multi-threaded events. So both!

72 points by relyio 9y ago

Modern processors are much faster than the outlying memory and persistent storage devices. They and compilers in combination are relatively good at optimizing for predictable patterns of using sequential blocks of the outlying memory. Context switches between tasks are expensive, because the state of the processor must be (at least partially) serialized and stored as well as the loss of the implicit context of the caches. Thus it makes /far/ more sense to have a number of threads (dependent on the hardware capacity and how readily the problem can be divided to independent or very loosely coupled tasks) which poll message queues than it does to have a completely independent thread for every event. Languages based around message passing are thus the obvious choice for this type of programming.

eggie5 9y ago
What modern server is this describing? "a number of threads ... which poll message queues..." and what is this describing? "...a completely independent thread for every event." "Languages based around message passing are thus the obvious choice for this type of programming." Ruby? Obj-c?
- mjevans 9y ago
  The two languages that come to /my/ mind are Erlang and Go. Other programmers might have different choices. There's no reason you couldn't use a language that has threads to implement the N threads with event queues model, or something similar for that language if it has shared memory. If the language of choice lacks it you might be able to use a similar multi-process (externally) load-balanced model.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
- mcguire 9y ago
  Pony. (https://www.ponylang.org https://www.ponylang.org) Actor-based programming model, where actors are Erlang-ish very lightweight green threads, running on a hardware thread per processor. Communicating by fast message passing.
buzzybee 9y ago
When the paper was written, the jury was still definitely out on good concurrency practices for applications: the computing world(apart from mainframes, which of course had learned every lesson 30 years earlier, but nobody paid much attention to) had only relatively recently exited the era where one might ordinarily synchronize your co-processing units at the instruction level, with hand-tuned assembly, just like any other piece of external hardware. Cooperative, event-based programming is familiar to this style. Asynchronous primitives backed by hardware scheduling were the "new kid" for a lot of programmers. So, like with every technology, there was some exuberance and overuse of a novel formalism which shows up in this paper: "scales to 100,000 threads", it proclaims. Not much later, interest in "green threading" and "lightweight concurrency" grew as a way to get some of the architectural benefits of being asynchronous while mitigating waste from large numbers of threads, and consensus shifted towards mixing the approaches, which seems to have converged on the few-threads, message-queue-per-thread approach.

metalliqaz 9y ago

Modern version of "considered harmful."

EGreg 9y ago

A few years later, Igor Sysoev will make NGinX which will blow Apache away in speed, and Apache 2 will adopt the paradigm.

SwellJoe 9y ago
There were many fast(er than Apache) web servers before nginx, many using various concurrency models, including the one used by nginx.

geezerjay 9y ago

here's a link to a related discussion on HN entitled Why Threads are a Bad Idea (for most purposes) (1995)" https://news.ycombinator.com/item?id=14547063 https://news.ycombinator.com/item?id=14547063

CodeWriter23 9y ago

Threads vs. events is a false dichotomy to me. Currently writing an event-driven finite state machine dispatcher that fires up threaded processes to perform long-running tasks that do not modify state. The FSM brings order and structure to chaotic event interactions, while threading enables full utilization of CPU cores. All the better to drain your battery, lol. Seriously though, I made this choice to balance reliability with responsivenes. Choose the right tool for the job.

bullen 9y ago
I agree that they are not contradictory but rather complementary: https://github.com/tinspin/rupy https://github.com/tinspin/rupy My web server uses multi-threaded events. So both!