6 ms·

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.)
    - phamilton 10y ago
      It's still an order of magnitude more than many green threads implementations. musl is interesting though. I've never seen it pitched as a solution for normal machines. I've always seen it in the context of small embedded systems.
    - pjmlp 10y ago
      Yeah, but that is a very specific OS stack, which cannot be generalized to language runtimes running on top of general purpose OSes. Now when targeting bare metal deployments like unikernels, it is a different story in how to approach it.
    - marcosdumay 10y ago
      Green threads usually take something on the order of 1kB per thread. That's an order of magnitude more threads per machine, but this is not even the greatest benefit. Green threads shine because they take ~1kB without tweaking. That means you just pack your software, send elsewhere, and you get those millions of threads per server, instead of losing hours on customer support, and have it revert to 10k threads at random because of bad sysadmins. Anyway, "thread" is not really a concurrency oriented concept. It mixes so much of parallelism that it's expected that it has some downsides compared o purely concurrent concepts.
- chubot 10y ago
  Yes I agree -- threads without shared state or with thread-safe shared data structures is a perfectly good programming paradigm (and pretty well proven too). One of my pet ideas is just to implement a Go-like CSP with plain pthreads. Channels could be pipes of pointers. Channel select is just select(). No weird M:N runtime needed. I don't want an operating system in my programming language. This is just stolen from Programming in Lua chapter 30 -- threads and states ( https://www.lua.org/pil/ https://www.lua.org/pil/ , not in the 1st online edition unfortunately) Lua has coroutines within the interpreter, but to utilize all the cores he suggests layering threads and multiple Lua interpreters on top.
  - Matthias247 10y ago
    That's probably a good idea. However it will most likely not work out with pipes as I don't know how you could implement the synchronous (unbuffered) channels with them. IMHO unbuffered channels are one of the most powerful constructs in Go, since they guarantee that "resources" are always on one-side of the channel and are taken care of, and never stored in a channel (or promise, ...) where they could get abondoned/lost. It also allows to make some other assumptions like "the in-memory server has taken my request through a channel and is now working on it and will answer through a chnanel soon" or "the server has shut down so I can't write to the channel", but never "the write to the channel succeeded but nobody cares about it".
    - pcwalton 10y ago
      > However it will most likely not work out with pipes as I don't know how you could implement the synchronous (unbuffered) channels with them. Easy. Just implement them with a mutex and a condvar. If you want, layer some lock free algorithm on top for the fast path.
      - chubot 10y ago
        Yeah actually the Lua implementation I mentioned uses a condition variable (not sure about the mutex). The unbuffered channel would be a good reason to use that scheme. I was thinking of using pipes so Go's select reduces to the select() system call. But I think you can just do both -- it's cheap. Write to a pipe and and notify a condition variable. I'll experiment with it.
- Matthias247 10y ago
  However from the learning side it doesn't really matter if you have to learn and apply synchronization in a 1:1 threaded or M:N threaded model. It's about the same. The more important difference is what kind of synchronization primitives are provided to you by the platform. Go's (synchronous) channels in combination with select provide a quite powerful tool compared to using only pthreads. Even the old WinApi with WaitForMultipleObjects and that stuff will result in other ways or solving typical concurrency problems.
bbcbasic 10y ago
Threads in JS?
- EdSharkey 10y ago
  Web workers are threaded.
  - hrjet 10y ago
    They are more akin to "processes", because they don't share state with each other or the main event loop.
  - throwaway2048 10y ago
    web workers are almost entirely useless due to the fact they cant interact with anything except a message channel. Serializing and deserializing everything so web workers can operate on it introduces more overhead than the parallel speedup is worth in the vast majority of cases. Not to mention stuff like DOM updates, web-sockets, or anything else cant be done by them, and are stuck on the main thread. They are really not comparable to threads.
    - jbergens 10y ago
      They are mostly done in order to free the ui "thread" to avoid getting ui freeze. The event loop is fast enough for most concurrency things in js client applications as long as you divide the tasks into smaller things.
    - EdSharkey 10y ago
      I suppose if you could only crunch numbers in a Web Worker and then make a clone to get it back to the DOM thread where it would be used, then yeah, Web Workers would be bleh. But, it's not as bad as all that! For example, transferables let you move bulk data between threads without cloning. At least that removes most of the communication overhead. https://developer.mozilla.org/en-US/docs/Web/API/Transferable https://developer.mozilla.org/en-US/docs/Web/API/Transferabl... On firefox you can transfer your WebGL canvas to a Web Worker, how is that for useful? https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/ https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/ You can use Web Sockets in Web Workers in very recent Firefox (48+?) and Chrome versions. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... And you've always been able to do AJAXy things on Web Workers as well. I'm not saying the API's are clean or lovely, but the multithreaded functionality is there for the taking.

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.)
  - phamilton 10y ago
    It's still an order of magnitude more than many green threads implementations. musl is interesting though. I've never seen it pitched as a solution for normal machines. I've always seen it in the context of small embedded systems.
  - pjmlp 10y ago
    Yeah, but that is a very specific OS stack, which cannot be generalized to language runtimes running on top of general purpose OSes. Now when targeting bare metal deployments like unikernels, it is a different story in how to approach it.
  - marcosdumay 10y ago
    Green threads usually take something on the order of 1kB per thread. That's an order of magnitude more threads per machine, but this is not even the greatest benefit. Green threads shine because they take ~1kB without tweaking. That means you just pack your software, send elsewhere, and you get those millions of threads per server, instead of losing hours on customer support, and have it revert to 10k threads at random because of bad sysadmins. Anyway, "thread" is not really a concurrency oriented concept. It mixes so much of parallelism that it's expected that it has some downsides compared o purely concurrent concepts.
chubot 10y ago
Yes I agree -- threads without shared state or with thread-safe shared data structures is a perfectly good programming paradigm (and pretty well proven too). One of my pet ideas is just to implement a Go-like CSP with plain pthreads. Channels could be pipes of pointers. Channel select is just select(). No weird M:N runtime needed. I don't want an operating system in my programming language. This is just stolen from Programming in Lua chapter 30 -- threads and states ( https://www.lua.org/pil/ https://www.lua.org/pil/ , not in the 1st online edition unfortunately) Lua has coroutines within the interpreter, but to utilize all the cores he suggests layering threads and multiple Lua interpreters on top.
- Matthias247 10y ago
  That's probably a good idea. However it will most likely not work out with pipes as I don't know how you could implement the synchronous (unbuffered) channels with them. IMHO unbuffered channels are one of the most powerful constructs in Go, since they guarantee that "resources" are always on one-side of the channel and are taken care of, and never stored in a channel (or promise, ...) where they could get abondoned/lost. It also allows to make some other assumptions like "the in-memory server has taken my request through a channel and is now working on it and will answer through a chnanel soon" or "the server has shut down so I can't write to the channel", but never "the write to the channel succeeded but nobody cares about it".
  - pcwalton 10y ago
    > However it will most likely not work out with pipes as I don't know how you could implement the synchronous (unbuffered) channels with them. Easy. Just implement them with a mutex and a condvar. If you want, layer some lock free algorithm on top for the fast path.
    - chubot 10y ago
      Yeah actually the Lua implementation I mentioned uses a condition variable (not sure about the mutex). The unbuffered channel would be a good reason to use that scheme. I was thinking of using pipes so Go's select reduces to the select() system call. But I think you can just do both -- it's cheap. Write to a pipe and and notify a condition variable. I'll experiment with it.
Matthias247 10y ago
However from the learning side it doesn't really matter if you have to learn and apply synchronization in a 1:1 threaded or M:N threaded model. It's about the same. The more important difference is what kind of synchronization primitives are provided to you by the platform. Go's (synchronous) channels in combination with select provide a quite powerful tool compared to using only pthreads. Even the old WinApi with WaitForMultipleObjects and that stuff will result in other ways or solving typical concurrency problems.

bbcbasic 10y ago

Threads in JS?

EdSharkey 10y ago
Web workers are threaded.
- hrjet 10y ago
  They are more akin to "processes", because they don't share state with each other or the main event loop.
- throwaway2048 10y ago
  web workers are almost entirely useless due to the fact they cant interact with anything except a message channel. Serializing and deserializing everything so web workers can operate on it introduces more overhead than the parallel speedup is worth in the vast majority of cases. Not to mention stuff like DOM updates, web-sockets, or anything else cant be done by them, and are stuck on the main thread. They are really not comparable to threads.
  - jbergens 10y ago
    They are mostly done in order to free the ui "thread" to avoid getting ui freeze. The event loop is fast enough for most concurrency things in js client applications as long as you divide the tasks into smaller things.
  - EdSharkey 10y ago
    I suppose if you could only crunch numbers in a Web Worker and then make a clone to get it back to the DOM thread where it would be used, then yeah, Web Workers would be bleh. But, it's not as bad as all that! For example, transferables let you move bulk data between threads without cloning. At least that removes most of the communication overhead. https://developer.mozilla.org/en-US/docs/Web/API/Transferable https://developer.mozilla.org/en-US/docs/Web/API/Transferabl... On firefox you can transfer your WebGL canvas to a Web Worker, how is that for useful? https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/ https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/ You can use Web Sockets in Web Workers in very recent Firefox (48+?) and Chrome versions. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... And you've always been able to do AJAXy things on Web Workers as well. I'm not saying the API's are clean or lovely, but the multithreaded functionality is there for the taking.