4 ms·

what about "green threads" that is not managed by the OS like https://tokio.rs https://tokio.rs ?

deleted 3y ago
[deleted]
kllrnohj 3y ago
You only ever need this if you're trying to have hundreds of thousands to millions of threads. It's a very niche problem to have
- OkayPhysicist 3y ago
  It's a niche problem to have because our current programming paradigm treats concurrency as a second-class citizen. The invariants of most languages do not include those required for mass concurrency. Functional programming better aligns with the requirements, which is how you arrive at Erlang and Elixir. Every map() function can be trivially replaced with the concurrent cmap(), because the side effects that would make it non-trivial are impossible to express. Given that Moore's law as it applied to single threaded performance is dead and in the ground, it makes a lot of sense to start paying more attention to systems that treat concurrency as more than an afterthought.
  - kllrnohj 3y ago
    Except in that scenario you absolutely don't want green threads but real threads. M:N threading (especially if N=1) doesn't help you get parallelism, and parallelism is what you need for modern CPUs. So that again keeps green threads (and thus mass concurrency without parallelism) in the niche category.
aleph_minus_one 3y ago
Green threads do not make use of multiple cores of a modern processor.
- preseinger 3y ago
  what makes you say this? go programs definitely saturate modern server-class CPUs
- jabl 3y ago
  It's entirely possible for a green threads implementation to schedule the green threads over multiple OS threads, thus making use of multiple cores. The programming language "Go" being a popular implementation of this.
- nextaccountic 3y ago
  M:N green threads run M green threads on N OS threads and thus use up to N processor cores
Const-me 3y ago
I believe these green threads work well when there’s good support in both language, runtime and standard library. I have built complicated concurrent software in C# with async-await. I don’t program golang but I heard the concurrency model works rather well in golang too, probably for the same reason as C#: good support in the language and the runtime. I have no idea about Tokyo. I don’t program Rust, and the feedback I read about async/await was mixed.
karelpeeters 3y ago
Tokio is using the Rust async features, which are not green threads. In the former code has to explicitly mark potential yield points, in the latter green threads can be scheduled by the runtime without any help from the code itself. As a historical note, Rust used to have green threads but they were abandoned a long time ago. This is a good talk about both the differences between different forms of concurrency/async and Rusts history with them: https://www.infoq.com/presentations/rust-2019/ https://www.infoq.com/presentations/rust-2019/ (includes a transcript)

deleted 3y ago

[deleted]

You only ever need this if you're trying to have hundreds of thousands to millions of threads. It's a very niche problem to have

OkayPhysicist 3y ago
It's a niche problem to have because our current programming paradigm treats concurrency as a second-class citizen. The invariants of most languages do not include those required for mass concurrency. Functional programming better aligns with the requirements, which is how you arrive at Erlang and Elixir. Every map() function can be trivially replaced with the concurrent cmap(), because the side effects that would make it non-trivial are impossible to express. Given that Moore's law as it applied to single threaded performance is dead and in the ground, it makes a lot of sense to start paying more attention to systems that treat concurrency as more than an afterthought.
- kllrnohj 3y ago
  Except in that scenario you absolutely don't want green threads but real threads. M:N threading (especially if N=1) doesn't help you get parallelism, and parallelism is what you need for modern CPUs. So that again keeps green threads (and thus mass concurrency without parallelism) in the niche category.

aleph_minus_one 3y ago

Green threads do not make use of multiple cores of a modern processor.

preseinger 3y ago
what makes you say this? go programs definitely saturate modern server-class CPUs
jabl 3y ago
It's entirely possible for a green threads implementation to schedule the green threads over multiple OS threads, thus making use of multiple cores. The programming language "Go" being a popular implementation of this.
nextaccountic 3y ago
M:N green threads run M green threads on N OS threads and thus use up to N processor cores

Const-me 3y ago

I believe these green threads work well when there’s good support in both language, runtime and standard library. I have built complicated concurrent software in C# with async-await. I don’t program golang but I heard the concurrency model works rather well in golang too, probably for the same reason as C#: good support in the language and the runtime. I have no idea about Tokyo. I don’t program Rust, and the feedback I read about async/await was mixed.

karelpeeters 3y ago

Tokio is using the Rust async features, which are not green threads. In the former code has to explicitly mark potential yield points, in the latter green threads can be scheduled by the runtime without any help from the code itself. As a historical note, Rust used to have green threads but they were abandoned a long time ago. This is a good talk about both the differences between different forms of concurrency/async and Rusts history with them: https://www.infoq.com/presentations/rust-2019/ https://www.infoq.com/presentations/rust-2019/ (includes a transcript)