6 ms·

After all the hoopla surrounding concurrency models, it seems that languages are conceding that green threads are more ergonomic to work with. Go and Java have

After all the hoopla surrounding concurrency models, it seems that languages are conceding that green threads are more ergonomic to work with. Go and Java have it, and now .NET is even experimenting with it. How long until OS vendors introduce abstractions to make this easier? Why aren't there OS-native green threads, or at the very least user-space scheduling affordances for runtimes that want to implement them without overhead in calling blocking code?

halayli 4y ago
bsd variants and sun os used to have n:m APIs but they got deprecated and removed long time ago. It's hard to provide a consistent behavior that works for everyone.
- smasher164 4y ago
  I said in a sibling comment that scheduler activations may have been a flawed idea, but I don’t think the space of user-space scheduling APIs is fully explored. Google’s ghOSt work is an example of that. If io-uring is proof of anything, it’s that there’s still fundamental changes we can make in how we schedule work with the kernel.
Jtsummers 4y ago
> Why aren't there OS-native green threads, or at the very least user-space scheduling affordances for runtimes that want to implement them without overhead in calling blocking code? Green threads are, definitionally, not OS threads, they are user space threads. So you will never see OS-native green threads as it's an oxymoron. The way many green thread systems work is to either lie to you (you really only have one OS thread, the green threads exist to write concurrent code, which can be much simpler, but not parallel code using Pike's distinction), or to introduce multiple OS threads ("carrier threads" in the terms of this article) which green threads are distributed across (this is what Java is doing here, Go has done for a long time, BEAM languages for a long time, and many others). EDIT: To extend this, many people think of "green threads" as lightweight threading mechanisms. That's kind of accurate for many systems, but not always true. If that's the sense that's meant, then OS-native lightweight threads are certainly possible in the future. But there's probably not much reason to add them when user space lightweight concurrency mechanisms already exist, and there's no consensus on which ones are "best" (by whatever metric).
- Sakos 4y ago
  > To extend this, many people think of "green threads" as lightweight threading mechanisms. That's kind of accurate for many systems, but not always true. If that's the sense that's meant, then OS-native lightweight threads are certainly possible in the future. But there's probably not much reason to add them when user space lightweight concurrency mechanisms already exist, and there's no consensus on which ones are "best" (by whatever metric). Wouldn't it make sense to implement them kernel-side when looking at how every programming language seems to have to reinvent the wheel regarding green threads?
  - Jtsummers 4y ago
    Green threads (today) aren't a singular thing, the definition is that they're in user space not kernel space. They are implemented in a variety of ways: https://en.wikipedia.org/wiki/Green_thread https://en.wikipedia.org/wiki/Green_thread Do you imitate a more traditional OS-thread style with preemption, do you use cooperating tasks, coroutines, what? Since there is no singular best or consensus model, there is little reason for an OS to adopt wholesale one of these variations at this time. The original green threads (from that page) shared one OS thread and used cooperative multitasking (most coroutine approaches would be analogous to this). But today, like with Go and BEAM languages, they're distributed across real OS threads to get parallelism. Which approach should an OS adopt? And if it did, would other languages/runtimes abandon their own models if it were significantly different?
    - smasher164 4y ago
      Preemptive threads with growable stacks. There was some discussion around getting segmented stacks into the kernel, but I'm not sure that's the best approach. There might have to be some novel work done in making contiguous stacks work in a shared address space.
  - wtetzner 4y ago
    I think the reasons green threads can work in languages is that the runtime understands the language semantics, and can take advantage of them. The OS doesn't understand the language and its concurrency semantics, and only has a blob of machine code to work with.
zozbot234 4y ago
> How long until OS vendors introduce abstractions to make this easier? The OS-level abstraction is called M:N threads. It has always been supported by Java on Solaris. But it's not really popular elsewhere.
MarkSweep 4y ago
Maybe ironically given all the green thread experiments in industry, but Microsoft just removed their user-mode scheduling library in Windows 11. https://learn.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling https://learn.microsoft.com/en-us/windows/win32/procthread/u...
lmm 4y ago
> After all the hoopla surrounding concurrency models, it seems that languages are conceding that green threads are more ergonomic to work with. Go and Java have it, and now .NET is even experimenting with it. Green threads were always better, the issue was compatibility with native (C) libraries. 20 years ago a language whose C FFI was as cumbersome as Go's would be laughed at. > How long until OS vendors introduce abstractions to make this easier? Why aren't there OS-native green threads, or at the very least user-space scheduling affordances for runtimes that want to implement them without overhead in calling blocking code? Most of the point of green threads is to avoid the OS getting in the way. Rather than OSes adding green threading, the future looks like sidestepping more and more of the traditional OS, ending up with unikernels or something that looks like them. The likes of graal native image are already a step in this direction.
- smasher164 4y ago
  > Green threads were always better There’s a lot of people who advocate otherwise, but I don’t think we have the mechanisms for effect polymorphism in current languages good enough to make effects ergonomic. > Most of the point of green threads is to avoid the OS getting in the way. I see the OS as an environment to help me run programs. Language runtimes have been taking over that role over the last few decades, sure. However, whether or not unikernels are the way forward remains to be seen. I still see it worthwhile to improve the OS, however.
  - pjmlp 4y ago
    The extent of the OS relevancy is inversely proportionaly to the richness of the language runtime and ecosystem. Or as Dan Ingalls from Smalltalk fame would put it, "an operating system is a collection of things that don't fit inside a language; there shouldn't be one". Incidently that is pretty much true for those of us doing distributed computing in cloud environments with managed languages, their runtimes could even be running directly on top of type 1 hypervisor for what I care.
dboreham 4y ago
There are : Fibers in NT for example.

halayli 4y ago

bsd variants and sun os used to have n:m APIs but they got deprecated and removed long time ago. It's hard to provide a consistent behavior that works for everyone.

smasher164 4y ago
I said in a sibling comment that scheduler activations may have been a flawed idea, but I don’t think the space of user-space scheduling APIs is fully explored. Google’s ghOSt work is an example of that. If io-uring is proof of anything, it’s that there’s still fundamental changes we can make in how we schedule work with the kernel.

Jtsummers 4y ago

> Why aren't there OS-native green threads, or at the very least user-space scheduling affordances for runtimes that want to implement them without overhead in calling blocking code? Green threads are, definitionally, not OS threads, they are user space threads. So you will never see OS-native green threads as it's an oxymoron. The way many green thread systems work is to either lie to you (you really only have one OS thread, the green threads exist to write concurrent code, which can be much simpler, but not parallel code using Pike's distinction), or to introduce multiple OS threads ("carrier threads" in the terms of this article) which green threads are distributed across (this is what Java is doing here, Go has done for a long time, BEAM languages for a long time, and many others). EDIT: To extend this, many people think of "green threads" as lightweight threading mechanisms. That's kind of accurate for many systems, but not always true. If that's the sense that's meant, then OS-native lightweight threads are certainly possible in the future. But there's probably not much reason to add them when user space lightweight concurrency mechanisms already exist, and there's no consensus on which ones are "best" (by whatever metric).

Sakos 4y ago
> To extend this, many people think of "green threads" as lightweight threading mechanisms. That's kind of accurate for many systems, but not always true. If that's the sense that's meant, then OS-native lightweight threads are certainly possible in the future. But there's probably not much reason to add them when user space lightweight concurrency mechanisms already exist, and there's no consensus on which ones are "best" (by whatever metric). Wouldn't it make sense to implement them kernel-side when looking at how every programming language seems to have to reinvent the wheel regarding green threads?
- Jtsummers 4y ago
  Green threads (today) aren't a singular thing, the definition is that they're in user space not kernel space. They are implemented in a variety of ways: https://en.wikipedia.org/wiki/Green_thread https://en.wikipedia.org/wiki/Green_thread Do you imitate a more traditional OS-thread style with preemption, do you use cooperating tasks, coroutines, what? Since there is no singular best or consensus model, there is little reason for an OS to adopt wholesale one of these variations at this time. The original green threads (from that page) shared one OS thread and used cooperative multitasking (most coroutine approaches would be analogous to this). But today, like with Go and BEAM languages, they're distributed across real OS threads to get parallelism. Which approach should an OS adopt? And if it did, would other languages/runtimes abandon their own models if it were significantly different?
  - smasher164 4y ago
    Preemptive threads with growable stacks. There was some discussion around getting segmented stacks into the kernel, but I'm not sure that's the best approach. There might have to be some novel work done in making contiguous stacks work in a shared address space.
- wtetzner 4y ago
  I think the reasons green threads can work in languages is that the runtime understands the language semantics, and can take advantage of them. The OS doesn't understand the language and its concurrency semantics, and only has a blob of machine code to work with.

zozbot234 4y ago

> How long until OS vendors introduce abstractions to make this easier? The OS-level abstraction is called M:N threads. It has always been supported by Java on Solaris. But it's not really popular elsewhere.

MarkSweep 4y ago

Maybe ironically given all the green thread experiments in industry, but Microsoft just removed their user-mode scheduling library in Windows 11. https://learn.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling https://learn.microsoft.com/en-us/windows/win32/procthread/u...

lmm 4y ago

> After all the hoopla surrounding concurrency models, it seems that languages are conceding that green threads are more ergonomic to work with. Go and Java have it, and now .NET is even experimenting with it. Green threads were always better, the issue was compatibility with native (C) libraries. 20 years ago a language whose C FFI was as cumbersome as Go's would be laughed at. > How long until OS vendors introduce abstractions to make this easier? Why aren't there OS-native green threads, or at the very least user-space scheduling affordances for runtimes that want to implement them without overhead in calling blocking code? Most of the point of green threads is to avoid the OS getting in the way. Rather than OSes adding green threading, the future looks like sidestepping more and more of the traditional OS, ending up with unikernels or something that looks like them. The likes of graal native image are already a step in this direction.

smasher164 4y ago
> Green threads were always better There’s a lot of people who advocate otherwise, but I don’t think we have the mechanisms for effect polymorphism in current languages good enough to make effects ergonomic. > Most of the point of green threads is to avoid the OS getting in the way. I see the OS as an environment to help me run programs. Language runtimes have been taking over that role over the last few decades, sure. However, whether or not unikernels are the way forward remains to be seen. I still see it worthwhile to improve the OS, however.
- pjmlp 4y ago
  The extent of the OS relevancy is inversely proportionaly to the richness of the language runtime and ecosystem. Or as Dan Ingalls from Smalltalk fame would put it, "an operating system is a collection of things that don't fit inside a language; there shouldn't be one". Incidently that is pretty much true for those of us doing distributed computing in cloud environments with managed languages, their runtimes could even be running directly on top of type 1 hypervisor for what I care.

dboreham 4y ago

There are : Fibers in NT for example.