4 ms·

The paper doesn't seem to discuss the important concept that writing threaded code is hard. Once your process starts using threads, suddenly every bit of state

The paper doesn't seem to discuss the important concept that writing threaded code is hard. Once your process starts using threads, suddenly every bit of state in it can be shared by all threads. Concurrency issues, locking and so on become major headaches. Reasoning about code paths and data accesses becomes amazingly complicated. We may think that we're coding experts, but throw us some threads and we'll screw up the code for them. Also, this paper is from over ten years ago. If the concept is correct, surely lots of threaded servers would have appeared and their speed would have been beating benchmarks all over the place. Where are these servers?

dozzie 13y ago
> Once your process starts using threads, suddenly every bit of state in it can be shared by all threads. Only when you use highly inconvenient model of shared memory. Message passing and shared-nothing combined, as it is done in Erlang or Go, are way easier to reason about, giving at the same time more natural way of structuring code than events handling.
- joosters 13y ago
  I agree! It's a shame that the most common concurrent programming models are a choice between share-nothing (fork) and share-everything (threads). Anything that gives a programmer something between the two extremes is an improvement.
- merijnv 13y ago
  Or when using the highly inconvenient model of mutable state ;) Purely functional language can share state between threads just fine, since any state will be immutable (barring any explicit communication primitives).
rdtsc 13y ago
> The paper doesn't seem to discuss the important concept that writing threaded code is hard. It mentions that using threads is hard. The implication is events are harder. > suddenly every bit of state in it can be shared by all threads. Long overlapping chains of callbacks have similar issues. Points where concurrency contexts switch are much larger (between callbacks instead of between machine instructions) but in a large system the danger is real. > Reasoning about code paths and data accesses becomes amazingly complicated. Based on working on large systems based on callbacks and based on threads, I've come to the conclusion that both are hard, but callbacks are much harder and messier. > Where are these servers? There are everywhere. Java, C++ backend systems. Twitter is using Scala. WhatsApp is using Erlang. PostgreSQL has background processes that help. Apache is the most popular web server. Now are you saying "where they are?" because we don't read about them on HN every day? Yeah, nobody talks about stuff that works and is established and boring. So perhaps picking technology based on what is read or discussed on HN might not be the best approach ;-)
- joosters 13y ago
  I didn't mean that threaded servers don't exist, that's pretty obvious. I meant, as my comment stated, that there aren't threaded servers popping up and demonstrating this fantastic performance/scalability. Hell, Apache moved away from threads. Twitter and WhatsApp could be good examples, but no-one outside the company can really say that each server there scales well. How many servers does Twitter run? Who knows? So who knows if they are each 'scaling to 100,000 threads and achieving excellent performance', as per the paper's claims? As for which model is harder or not, I guess that is an arguable matter of opinion. When the paper is claiming that one model is a 'more natural' programming style then it's clearly moving beyond objective reasoning.
  - jlouis 13y ago
    Erlang routinely runs 100,000 processes in the same memory space and scales very well. The reason it is possible to even handle this is that it is not based on shared memory but on message passing. There are two things at play here: a) Is the solution easy to design/code. b) Is the solution fast enough. There is far too much focus on (b) and relatively little attention is given to (a). The claim is that writing code in a direct style in a highly concurrent environment (Go, Erlang, Haskell, SML, ...) is easier and achieves roughly the same performance (within a factor of, say, 2). My experience is that this is true. I have seen fast evented and threaded systems. But I do feel the threaded systems were easier to write.
    - tel 13y ago
      Another side effect of focusing on (b) is that it frees up the resources someone else (a runtime implementer) has to focus on (a) independently. This is just another corollary of "build it, build it right, build it fast". In particular, consider the new MIO IO manager included in Haskell GHC 7.8. It's increasing performance of IO-bound lightweight threading by orders of magnitude... all performance provided completely for free to consumers of these abstract threading services who've spent all their time making their algorithms correct, not fast.
  - deleted 13y ago
    [deleted]
Nursie 13y ago
>> We may think that we're coding experts, but throw us some threads and we'll screw up the code for them. I dispute this. With a functional* approach to writing discrete, modular code with locking as fine-grained and minimal as possible, it's not that hard. Lot's of threaded servers have appeared. They are, as others have said, absolutely everywhere. *(not pure functional, just functional as an approach, i.e. writing C code in a side-effect and state-free manner as far as possible)
- Jtsummers 13y ago
  Unfortunately this (in a language like C where it's not encouraged/enforced by design) requires discipline and experience. As evidenced by some colleagues, without experienced leadership on a project a group of journeyman programmers can produce some incredibly creatively broken multithreaded code. The experience part can be taught, discipline can be encouraged and developed with the right leaders/mentors. But without motivated individuals on the team (to learn this particular aspect of development) or mentors/leaders pushing/pulling them along, it's unlikely to happen until it's too late. But, some people have to fail before they learn. Just wish they hadn't failed on such a big project.

dozzie 13y ago

> Once your process starts using threads, suddenly every bit of state in it can be shared by all threads. Only when you use highly inconvenient model of shared memory. Message passing and shared-nothing combined, as it is done in Erlang or Go, are way easier to reason about, giving at the same time more natural way of structuring code than events handling.

joosters 13y ago
I agree! It's a shame that the most common concurrent programming models are a choice between share-nothing (fork) and share-everything (threads). Anything that gives a programmer something between the two extremes is an improvement.
merijnv 13y ago
Or when using the highly inconvenient model of mutable state ;) Purely functional language can share state between threads just fine, since any state will be immutable (barring any explicit communication primitives).

rdtsc 13y ago

> The paper doesn't seem to discuss the important concept that writing threaded code is hard. It mentions that using threads is hard. The implication is events are harder. > suddenly every bit of state in it can be shared by all threads. Long overlapping chains of callbacks have similar issues. Points where concurrency contexts switch are much larger (between callbacks instead of between machine instructions) but in a large system the danger is real. > Reasoning about code paths and data accesses becomes amazingly complicated. Based on working on large systems based on callbacks and based on threads, I've come to the conclusion that both are hard, but callbacks are much harder and messier. > Where are these servers? There are everywhere. Java, C++ backend systems. Twitter is using Scala. WhatsApp is using Erlang. PostgreSQL has background processes that help. Apache is the most popular web server. Now are you saying "where they are?" because we don't read about them on HN every day? Yeah, nobody talks about stuff that works and is established and boring. So perhaps picking technology based on what is read or discussed on HN might not be the best approach ;-)

joosters 13y ago
I didn't mean that threaded servers don't exist, that's pretty obvious. I meant, as my comment stated, that there aren't threaded servers popping up and demonstrating this fantastic performance/scalability. Hell, Apache moved away from threads. Twitter and WhatsApp could be good examples, but no-one outside the company can really say that each server there scales well. How many servers does Twitter run? Who knows? So who knows if they are each 'scaling to 100,000 threads and achieving excellent performance', as per the paper's claims? As for which model is harder or not, I guess that is an arguable matter of opinion. When the paper is claiming that one model is a 'more natural' programming style then it's clearly moving beyond objective reasoning.
- jlouis 13y ago
  Erlang routinely runs 100,000 processes in the same memory space and scales very well. The reason it is possible to even handle this is that it is not based on shared memory but on message passing. There are two things at play here: a) Is the solution easy to design/code. b) Is the solution fast enough. There is far too much focus on (b) and relatively little attention is given to (a). The claim is that writing code in a direct style in a highly concurrent environment (Go, Erlang, Haskell, SML, ...) is easier and achieves roughly the same performance (within a factor of, say, 2). My experience is that this is true. I have seen fast evented and threaded systems. But I do feel the threaded systems were easier to write.
  - tel 13y ago
    Another side effect of focusing on (b) is that it frees up the resources someone else (a runtime implementer) has to focus on (a) independently. This is just another corollary of "build it, build it right, build it fast". In particular, consider the new MIO IO manager included in Haskell GHC 7.8. It's increasing performance of IO-bound lightweight threading by orders of magnitude... all performance provided completely for free to consumers of these abstract threading services who've spent all their time making their algorithms correct, not fast.
- deleted 13y ago
  [deleted]

Nursie 13y ago

>> We may think that we're coding experts, but throw us some threads and we'll screw up the code for them. I dispute this. With a functional* approach to writing discrete, modular code with locking as fine-grained and minimal as possible, it's not that hard. Lot's of threaded servers have appeared. They are, as others have said, absolutely everywhere. *(not pure functional, just functional as an approach, i.e. writing C code in a side-effect and state-free manner as far as possible)

Jtsummers 13y ago
Unfortunately this (in a language like C where it's not encouraged/enforced by design) requires discipline and experience. As evidenced by some colleagues, without experienced leadership on a project a group of journeyman programmers can produce some incredibly creatively broken multithreaded code. The experience part can be taught, discipline can be encouraged and developed with the right leaders/mentors. But without motivated individuals on the team (to learn this particular aspect of development) or mentors/leaders pushing/pulling them along, it's unlikely to happen until it's too late. But, some people have to fail before they learn. Just wish they hadn't failed on such a big project.