Why Events Are a Bad Idea (for high-concurrency servers) (2003) [pdf](people.eecs.berkeley.edu)
people.eecs.berkeley.edu
Why Events Are a Bad Idea (for high-concurrency servers) (2003) [pdf]
https://people.eecs.berkeley.edu/~brewer/papers/threads-hotos-2003.pdf
5 comments
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.
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.
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?
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?
Pony. (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.
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.
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.
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]
[deleted]
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.
Choose the right tool for the job.
I agree that they are not contradictory but rather complementary: https://github.com/tinspin/rupy
My web server uses multi-threaded events.
So both!
My web server uses multi-threaded events.
So both!
Modern version of "considered harmful."
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
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.