3 ms·

> I am not sure how "native threads" == "green threads" You are still confused. Green threads and native threads are mutually exclusive implementation strate

by lisper 4y ago

> I am not sure how "native threads" == "green threads" You are still confused. Green threads and native threads are mutually exclusive implementation strategies for threads. Native threads are provided by the O/S. Green threads are implemented at the user level without relying on any O/S capabilities. Green threads, by definition, run in a single O/S process and can therefore only use one core. > look up Erlang/Elixir's model, or Golang's, or Rust's async workers I'm familiar with those. Those are not "green threads". But whatever you call them, you can do those things in Lisp too.

pdimitar 4y ago
> you can do those things in Lisp too Well if you can that would be a huge step. Gotta check again it seems.
- lisper 4y ago
  The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.
  - pdimitar 4y ago
    Not convinced. If it's so easy why hasn't anyone done it yet and made it easy to consume for everyone else? To me this is a red flag. "Just roll it yourself" is not a constructive response in the eyes of a commercial programmer. We come to an ecosystem expecting certain basic building blocks. I am not paid to evolve LISP's ecosystem. Not to mention nobody will give me the time in a world where deadlines and milestones are a fact of life. If I was doing programming purely as a hobby -- sure! But I don't. And I'd bet most commercial programmers don't as well.
    - lisper 4y ago
      > why hasn't anyone done it yet and made it easy to consume for everyone else? Dunno. No demand? No standard? I recently wrote a library like this for my job. It took me about a day. I haven't published it because it was a work for hire and so it's not mine to publish. But it's the basis for my confidence that it's not hard to do. If you want to write up a spec, I'm available for contract work (and I'm sure you would have people lining up if you actually were willing to pay someone to do this work). But I suspect you would find that writing the spec is the hard part, and if you actually did it you would find that it's easier to implement yourself than to try to hire someone.
      - pdimitar 4y ago
        I mean, high-quality work should be paid. Obviously. But now we're making a full U-turn to my initial argument: LISP doesn't have features that I find are (or should be) basic building blocks so I am just taking my business elsewhere.
        lisper 4y ago
        But it does. Allegro CL has it. Other implementation might have it too. It's hard to say because you've been very vague about exactly what it is that you want.
        pdimitar 4y ago
        Was I vague? Or were you being overly pedant about Wikipedia-sourced definitions that, as another commenter pointed out, are kind of outdated? And now trying to frame me as not knowing what I want? And pretending that the examples I gave about three other languages don't paint the picture well enough? You seem to be arguing in bad faith from where I am standing. ...And okay -- I'd like a M:N green threads runtime (or library if you prefer) with preemptive scheduling or at least not a completely manual cooperative scheduling. And yes, we're talking full 100% CPU usage on all cores when needed. Not single-thread. And to repeat, since you kind of pretended I never said anything about what other languages do, and if you are indeed aware of how Erlang's BEAM VM is doing it -- that is what should be present in more than one language / runtime IMO. Failing that, Golang's goroutines and Rust's async workers+channels are quite fine too. To me, in 2023, no language has an excuse for not having something like that. Modern example: OCaml team worked on it for years and recently delivered it.
  - Blackthorn 4y ago
    No, I go not think this particular feature can be added at the user level. It's something that requires significant support from the runtime to handle all the blocking -> thread parking shenanigans. Attempts to do it at the user level are terribly limited in that respect and just end up like clojure's core.async.
    - lisper 4y ago
      You're not wrong, but most modern CL implementations provide all the primitives you need even if they don't go all the way and provide a fully-fledged Erlang-style parallelism library out of the box.
jcranmer 4y ago
FWIW, you are literally the first person I've seen who has insisted that green threads are incompatible with an M:N threading model. Every other definition I've seen for green threads is that they involve userspace scheduling, and there's no requirement that there must be but one thing that something can be scheduled onto.
- lisper 4y ago
  It's possible that the definition has changed; (human) language is malleable. But the original definition of "green thread", which goes back at least to the 1990s, was in contrast to "native thread" where the latter was implemented by the operating system and the former by the language implementation. The whole point of "green threads" was that they let you do something that looked like parallel processing (but was really just time-slicing under the hood) with no support from the O/S. If there's a new accepted definition someone should update the Wikipedia page.
  - skissane 4y ago
    Traditional, purist definitions: 1:1 threading = native threads, N:1 threading = green threads, M:N threading = hybrid threads (since it is a hybrid of the native and green approaches) However, a lot of people nowadays call M:N threading "green" instead of "hybrid". Just Google it you will find lots of people using the term in this way. From a traditional purist viewpoint it is an incorrect usage, but it is also now very common. I guess part of the reason is that green threads in the original sense is less useful today – one of the major historical motivators was it could run on OS platforms which lacked native threads, which was a common problem in the mid-1990s and earlier but nowadays almost never is – so it is unsurprising the term gets stolen for a closely related yet distinct technology with far greater contemporary usefulness. Wikipedia's article – https://en.wikipedia.org/wiki/Green_thread https://en.wikipedia.org/wiki/Green_thread – essentially contradicts itself. The start of the article gives the traditional definition of "green threads". But then the "Green threads in other languages" section ends up describing lots of things which are much closer to being "hybrid threads" than "green threads". This is the problem with an "encyclopaedia which anyone can edit", it is easy to unintentionally edit an article into contradicting itself, and on highly technical topics it is easy for the contradiction to go unnoticed. I myself am not sure I can fix it, because although I know the true story about the definitions (or at least I think I do), I don't know any reliable source to cite for it. Their thread article – https://en.wikipedia.org/wiki/Thread_(computing)#Threading_models https://en.wikipedia.org/wiki/Thread_(computing)#Threading_m... – does define M:N as "hybrid threading", whereas it calls N:1 "user-level threading". It also notes "green threads" as a synonym for "user threads"–but "user threads" aka "green threads" exist in both the M:N and N:1 models. It never defines "green threads" as a model as opposed to as a type of thread which exists in two out of the three models.

by lisper 4y ago

pdimitar 4y ago

> you can do those things in Lisp too Well if you can that would be a huge step. Gotta check again it seems.

lisper 4y ago
The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.
- pdimitar 4y ago
  Not convinced. If it's so easy why hasn't anyone done it yet and made it easy to consume for everyone else? To me this is a red flag. "Just roll it yourself" is not a constructive response in the eyes of a commercial programmer. We come to an ecosystem expecting certain basic building blocks. I am not paid to evolve LISP's ecosystem. Not to mention nobody will give me the time in a world where deadlines and milestones are a fact of life. If I was doing programming purely as a hobby -- sure! But I don't. And I'd bet most commercial programmers don't as well.
  - lisper 4y ago
    > why hasn't anyone done it yet and made it easy to consume for everyone else? Dunno. No demand? No standard? I recently wrote a library like this for my job. It took me about a day. I haven't published it because it was a work for hire and so it's not mine to publish. But it's the basis for my confidence that it's not hard to do. If you want to write up a spec, I'm available for contract work (and I'm sure you would have people lining up if you actually were willing to pay someone to do this work). But I suspect you would find that writing the spec is the hard part, and if you actually did it you would find that it's easier to implement yourself than to try to hire someone.
    - pdimitar 4y ago
      I mean, high-quality work should be paid. Obviously. But now we're making a full U-turn to my initial argument: LISP doesn't have features that I find are (or should be) basic building blocks so I am just taking my business elsewhere.
      - lisper 4y ago
        But it does. Allegro CL has it. Other implementation might have it too. It's hard to say because you've been very vague about exactly what it is that you want.
        pdimitar 4y ago
        Was I vague? Or were you being overly pedant about Wikipedia-sourced definitions that, as another commenter pointed out, are kind of outdated? And now trying to frame me as not knowing what I want? And pretending that the examples I gave about three other languages don't paint the picture well enough? You seem to be arguing in bad faith from where I am standing. ...And okay -- I'd like a M:N green threads runtime (or library if you prefer) with preemptive scheduling or at least not a completely manual cooperative scheduling. And yes, we're talking full 100% CPU usage on all cores when needed. Not single-thread. And to repeat, since you kind of pretended I never said anything about what other languages do, and if you are indeed aware of how Erlang's BEAM VM is doing it -- that is what should be present in more than one language / runtime IMO. Failing that, Golang's goroutines and Rust's async workers+channels are quite fine too. To me, in 2023, no language has an excuse for not having something like that. Modern example: OCaml team worked on it for years and recently delivered it.
- Blackthorn 4y ago
  No, I go not think this particular feature can be added at the user level. It's something that requires significant support from the runtime to handle all the blocking -> thread parking shenanigans. Attempts to do it at the user level are terribly limited in that respect and just end up like clojure's core.async.
  - lisper 4y ago
    You're not wrong, but most modern CL implementations provide all the primitives you need even if they don't go all the way and provide a fully-fledged Erlang-style parallelism library out of the box.

jcranmer 4y ago

FWIW, you are literally the first person I've seen who has insisted that green threads are incompatible with an M:N threading model. Every other definition I've seen for green threads is that they involve userspace scheduling, and there's no requirement that there must be but one thing that something can be scheduled onto.

lisper 4y ago
It's possible that the definition has changed; (human) language is malleable. But the original definition of "green thread", which goes back at least to the 1990s, was in contrast to "native thread" where the latter was implemented by the operating system and the former by the language implementation. The whole point of "green threads" was that they let you do something that looked like parallel processing (but was really just time-slicing under the hood) with no support from the O/S. If there's a new accepted definition someone should update the Wikipedia page.
- skissane 4y ago
  Traditional, purist definitions: 1:1 threading = native threads, N:1 threading = green threads, M:N threading = hybrid threads (since it is a hybrid of the native and green approaches) However, a lot of people nowadays call M:N threading "green" instead of "hybrid". Just Google it you will find lots of people using the term in this way. From a traditional purist viewpoint it is an incorrect usage, but it is also now very common. I guess part of the reason is that green threads in the original sense is less useful today – one of the major historical motivators was it could run on OS platforms which lacked native threads, which was a common problem in the mid-1990s and earlier but nowadays almost never is – so it is unsurprising the term gets stolen for a closely related yet distinct technology with far greater contemporary usefulness. Wikipedia's article – https://en.wikipedia.org/wiki/Green_thread https://en.wikipedia.org/wiki/Green_thread – essentially contradicts itself. The start of the article gives the traditional definition of "green threads". But then the "Green threads in other languages" section ends up describing lots of things which are much closer to being "hybrid threads" than "green threads". This is the problem with an "encyclopaedia which anyone can edit", it is easy to unintentionally edit an article into contradicting itself, and on highly technical topics it is easy for the contradiction to go unnoticed. I myself am not sure I can fix it, because although I know the true story about the definitions (or at least I think I do), I don't know any reliable source to cite for it. Their thread article – https://en.wikipedia.org/wiki/Thread_(computing)#Threading_models https://en.wikipedia.org/wiki/Thread_(computing)#Threading_m... – does define M:N as "hybrid threading", whereas it calls N:1 "user-level threading". It also notes "green threads" as a synonym for "user threads"–but "user threads" aka "green threads" exist in both the M:N and N:1 models. It never defines "green threads" as a model as opposed to as a type of thread which exists in two out of the three models.