4 ms·

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 u

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.

smasher164 4y ago
Not really tbh. The Go runtime has a work-stealing scheduler and does a lot of work to provide the same abstractions that pthreads have, but for goroutines.
- throwawaymaths 4y ago
  Erlang runtime has a work stealing scheduler but it has specific constraints like "how to make sure each running execution context gets a fair share of time and can't lock up the VM (I think you can still lock the go VM with an infinite loop)... So each VM has different concerns.
  - smasher164 4y ago
    > still lock the go VM with an infinite loop This is no longer an issue now with Go's async preemption. Also, this is less a "language-level concern" and more a consequence of a poor implementation of preemptive scheduling. Moreover, this is something OS threads already support.
    - throwawaymaths 4y ago
      Yes, but os threads come with overheads during context switches and for sure during the startup/teardown because you have to take a trip to the kernel to do those things. I don't see how it should be the os's business how to do m:n green threads. I think BEAM, for example can do a lot of clever coordination-free scheduling (it implements mutexes which are aware of the scheduling layout and I think don't bother to coordinate if they aren't necessary). In Erlang, the GC is green-thread aware, since green threads in Erlang don't share much memory -- I don't think there is a good generalized way for an OS to know these sorts of things without kneecapping some pl or another. Arguably a better place for this is the standard library of your (low level) PL. I think rust and zig do this.
      - smasher164 4y ago
        Project Loom experimentally proved that the benefit of virtual lies not in its fast context switches, but in the throughput afforded by having so many threads executed at once. I am aware of GC-aware green threads. They allow you to combine your GC pause and scheduler pause into one. Again, this is not the end of the world, even when you don’t have shared mutable state. If anything, it makes it easier to build a runtime on top of.
        throwawaymaths 4y ago
        > If anything, it makes it easier to build a runtime on top of. This is not the point. The point is that it would be very difficult to make an OS green thread that is aware of the runtime's GC, given that an OS will probably want to also support non-gc languages.
  - pessimizer 4y ago
    > constraints like "how to make sure each running execution context gets a fair share of time and can't lock up the VM IIRC that's because it preempts based on reduction counts rather than waiting on some thread to decide to yield itself.
    - throwawaymaths 4y ago
      Yeah, that's not easy for an OS to figure out from below.

smasher164 4y ago

Not really tbh. The Go runtime has a work-stealing scheduler and does a lot of work to provide the same abstractions that pthreads have, but for goroutines.

throwawaymaths 4y ago
Erlang runtime has a work stealing scheduler but it has specific constraints like "how to make sure each running execution context gets a fair share of time and can't lock up the VM (I think you can still lock the go VM with an infinite loop)... So each VM has different concerns.
- smasher164 4y ago
  > still lock the go VM with an infinite loop This is no longer an issue now with Go's async preemption. Also, this is less a "language-level concern" and more a consequence of a poor implementation of preemptive scheduling. Moreover, this is something OS threads already support.
  - throwawaymaths 4y ago
    Yes, but os threads come with overheads during context switches and for sure during the startup/teardown because you have to take a trip to the kernel to do those things. I don't see how it should be the os's business how to do m:n green threads. I think BEAM, for example can do a lot of clever coordination-free scheduling (it implements mutexes which are aware of the scheduling layout and I think don't bother to coordinate if they aren't necessary). In Erlang, the GC is green-thread aware, since green threads in Erlang don't share much memory -- I don't think there is a good generalized way for an OS to know these sorts of things without kneecapping some pl or another. Arguably a better place for this is the standard library of your (low level) PL. I think rust and zig do this.
    - smasher164 4y ago
      Project Loom experimentally proved that the benefit of virtual lies not in its fast context switches, but in the throughput afforded by having so many threads executed at once. I am aware of GC-aware green threads. They allow you to combine your GC pause and scheduler pause into one. Again, this is not the end of the world, even when you don’t have shared mutable state. If anything, it makes it easier to build a runtime on top of.
      - throwawaymaths 4y ago
        > If anything, it makes it easier to build a runtime on top of. This is not the point. The point is that it would be very difficult to make an OS green thread that is aware of the runtime's GC, given that an OS will probably want to also support non-gc languages.
- pessimizer 4y ago
  > constraints like "how to make sure each running execution context gets a fair share of time and can't lock up the VM IIRC that's because it preempts based on reduction counts rather than waiting on some thread to decide to yield itself.
  - throwawaymaths 4y ago
    Yeah, that's not easy for an OS to figure out from below.