7 ms·

Is there an article or book where the major "ways" of doing concurrency in different languages are explained and compared? E.g. thread process mutex semaphore e

Is there an article or book where the major "ways" of doing concurrency in different languages are explained and compared? E.g. thread process mutex semaphore etc. in Java et al, callback promise async await in JS, goroutine channel in Go, task async await plinq in C#, asyncio in Python, etc. It would be nice to have a general overview of these, what their pros and cons are and why.

specialist 10y ago
Pretty good survey. Seven Concurrency Models in Seven Weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in... https://www.amazon.com/Seven-Concurrency-Models-Weeks-Programmers/dp/1937785653 https://www.amazon.com/Seven-Concurrency-Models-Weeks-Progra...
- tucif 10y ago
  I believe this one does not addresses async-await in any of its implementations directly, does it? But it looks pretty interesting to cover other concurrency models.
  - Matthias247 10y ago
    Actually it doesn't cover promises/tasks/rx or any other monadic stuff at all. The Clojure part also is probably not the most practical since it lacks core.async. However it's still a very good read and highly recommended. One reason is that it covers most of the concepts that make up a solid concurrent program (immutability, sharing data by communicating, ...).
camwest 10y ago
I found this a good resource: http://berb.github.io/diploma-thesis/ http://berb.github.io/diploma-thesis/
- crudbug 10y ago
  I read this couple of days back, very well written.
bcheung 10y ago
It's much broader but if you are into that kind of thing this book has a broad survey of programming language concepts and how different languages implement different features. https://www.amazon.com/Programming-Language-Pragmatics-Fourth-Michael/dp/0124104096 https://www.amazon.com/Programming-Language-Pragmatics-Fourt... It's pretty easy to read for most programmers who are familiar with a few family of programming languages.
necessity 10y ago
There's probably more than one way of doing in it every language (e.g. in C you can use pthreads, OpenMP, C11 threads, etc). and I doubt any book/article would be complete and current.
jacobsenscott 10y ago
Ugh. At least when everyone was doing threads you only had to learn one model. Then everyone had to build a better mousetrap.
- pcwalton 10y ago
  I feel as though 1:1 threading is underrated nowadays. Most of the cited benefits of async or M:N—especially small stacks—are actually properties that can apply equally well to plain old 1:1 threading as well. Linux thread spawning is really fast nowadays.
  - phamilton 10y ago
    Thread spawning is fast but footprints are still pretty large. You'll likely max out around 10k threads with defaults, and maybe tweak it to 100k with small stack sizes.
    - pcwalton 10y ago
      Last time this came up, it was found that you can get per thread overhead down to 10KB with musl and Linux, and even smaller with upcoming Linux kernel work. That allows for quite a few more than 100,000 threads for typical server RAM configurations.
      - chubot 10y ago
        FWIW, there was an async vs. threads debate at Google that was "resolved" with one very important application running tens of thousands of threads per machine on hundreds of thousands of cores. Some people thought async would be a wiser architecture, but it was made to work (albeit with significant and literally full-stack engineering effort). The problem of threads vs async in C seems pretty well studied, but a more interesting question is what we're talking about here: concurrency models in higher level languages: async/await in JavaScript vs. threads in JavaScript. Or let's say Python, because it actually has threads. I feel like that tradeoff has been less well studied. Interpreters probably use a lot more stack space than native programs, but I wonder if anyone has quantified it. And on the other hand, the downside of async is less pronounced than in C -- the whole point is to avoid "stack ripping" and explicit state machines. And I have to echo the recent post here about the complexity of the async/await mechanisms in Python, although honestly I'm not that well-versed in the model. https://news.ycombinator.com/item?id=12829759 https://news.ycombinator.com/item?id=12829759 (Interesting that the top comment there is kind of echoing our issue with M:N threading -- the inner platform effect.)
jrowley 10y ago
Slightly off topic but you may also want to check out Leslie Lamport's classic Teaching Concurrency. http://research.microsoft.com/en-us/um/people/lamport/pubs/teaching-concurrency.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/t...

specialist 10y ago

Pretty good survey. Seven Concurrency Models in Seven Weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in... https://www.amazon.com/Seven-Concurrency-Models-Weeks-Programmers/dp/1937785653 https://www.amazon.com/Seven-Concurrency-Models-Weeks-Progra...

tucif 10y ago
I believe this one does not addresses async-await in any of its implementations directly, does it? But it looks pretty interesting to cover other concurrency models.
- Matthias247 10y ago
  Actually it doesn't cover promises/tasks/rx or any other monadic stuff at all. The Clojure part also is probably not the most practical since it lacks core.async. However it's still a very good read and highly recommended. One reason is that it covers most of the concepts that make up a solid concurrent program (immutability, sharing data by communicating, ...).

camwest 10y ago

I found this a good resource: http://berb.github.io/diploma-thesis/ http://berb.github.io/diploma-thesis/

crudbug 10y ago
I read this couple of days back, very well written.

bcheung 10y ago

It's much broader but if you are into that kind of thing this book has a broad survey of programming language concepts and how different languages implement different features. https://www.amazon.com/Programming-Language-Pragmatics-Fourth-Michael/dp/0124104096 https://www.amazon.com/Programming-Language-Pragmatics-Fourt... It's pretty easy to read for most programmers who are familiar with a few family of programming languages.

necessity 10y ago

There's probably more than one way of doing in it every language (e.g. in C you can use pthreads, OpenMP, C11 threads, etc). and I doubt any book/article would be complete and current.

jacobsenscott 10y ago

Ugh. At least when everyone was doing threads you only had to learn one model. Then everyone had to build a better mousetrap.

pcwalton 10y ago
I feel as though 1:1 threading is underrated nowadays. Most of the cited benefits of async or M:N—especially small stacks—are actually properties that can apply equally well to plain old 1:1 threading as well. Linux thread spawning is really fast nowadays.
- phamilton 10y ago
  Thread spawning is fast but footprints are still pretty large. You'll likely max out around 10k threads with defaults, and maybe tweak it to 100k with small stack sizes.
  - pcwalton 10y ago
    Last time this came up, it was found that you can get per thread overhead down to 10KB with musl and Linux, and even smaller with upcoming Linux kernel work. That allows for quite a few more than 100,000 threads for typical server RAM configurations.
    - chubot 10y ago
      FWIW, there was an async vs. threads debate at Google that was "resolved" with one very important application running tens of thousands of threads per machine on hundreds of thousands of cores. Some people thought async would be a wiser architecture, but it was made to work (albeit with significant and literally full-stack engineering effort). The problem of threads vs async in C seems pretty well studied, but a more interesting question is what we're talking about here: concurrency models in higher level languages: async/await in JavaScript vs. threads in JavaScript. Or let's say Python, because it actually has threads. I feel like that tradeoff has been less well studied. Interpreters probably use a lot more stack space than native programs, but I wonder if anyone has quantified it. And on the other hand, the downside of async is less pronounced than in C -- the whole point is to avoid "stack ripping" and explicit state machines. And I have to echo the recent post here about the complexity of the async/await mechanisms in Python, although honestly I'm not that well-versed in the model. https://news.ycombinator.com/item?id=12829759 https://news.ycombinator.com/item?id=12829759 (Interesting that the top comment there is kind of echoing our issue with M:N threading -- the inner platform effect.)

jrowley 10y ago

Slightly off topic but you may also want to check out Leslie Lamport's classic Teaching Concurrency. http://research.microsoft.com/en-us/um/people/lamport/pubs/teaching-concurrency.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/t...