4 ms·

I've noticed that lots of recent advances in threading are all just ways to avoid context switching of threads and instead handle those switches manually (e.g.

I've noticed that lots of recent advances in threading are all just ways to avoid context switching of threads and instead handle those switches manually (e.g. "green threads" in Python).

pvg 10y ago
These aren't particularly recent. Java originally had green threads; I think the term itself is from there.
- wavesplash 10y ago
  Green threads were a thing long before Java.
  - pvg 10y ago
    The term, not the variety of threads. I can't find any mention of it pre '95 or so, at least.
    - markkanof 10y ago
      '95, so about when significant amounts of information started being put on the internet?
      - pvg 10y ago
        I'm not so sure about the term 'green threads' but the internet was definitely around well before '95. There doesn't seem to be any mention of 'green threads' in available USENET archives before then, for instance. But if you know of one, anywhere, by all means, I'd love to hear about it.
        fit2rule 10y ago
        I think MIPS RISC/Os had 'green' threads in the 80's, or I could be mixing it up with Tandem terminology, where Fiber was a constant type, I seem to recall .. either way, the idea of a userspace-managed thread scheme is as old as the hills. The question has always been: who deals out the work, the OS or the App? and as we can see, the question will continue to be asked, and un-answered, probably ad infinitum ..
        pvg 10y ago
        Did it call them 'green threads'? If not, the terminology itself probably doesn't come from there.
        fit2rule 10y ago
        I do remember Tandem and/or Wang talking about green (transportable) threads who were okay to suspend/resume across processor units .. I wish I could find more info, but I really do recall the term being applicable way back when ..
        markkanof 10y ago
        What I was getting at was that around '95 was when the internet was really starting to come into generalized usage and exponentially more information published on the internet at that time than before. So maybe an internet search wouldn't turn up results, not because the term wasn't in existence prior to '95 but because the term wasn't published on the internet prior to '95.
  - polskibus 10y ago
    Erlang had green threads from the very beginning, in the 80s.
    - pvg 10y ago
      Erlang processes aren't threads and aren't called 'green' so I don't see how the term itself could have originated there.
- dragonwriter 10y ago
  Wikipedia agrees with you on the source of the term. Both the M:N and N:1 threading models themselves are older than Java, but the term "green threads" seems to have come from there.
  - pvg 10y ago
    Oh I didn't notice the wikipedia thing was actually sourced. I think that pretty much settles it. http://web.archive.org/web/20080530073139/http://java.sun.com/features/1998/05/birthday.html http://web.archive.org/web/20080530073139/http://java.sun.co...
lmm 10y ago
OS-level threads are a crude big hammer way of doing parallelism - want to run a task? Just switch out the whole 8kb of stack, then switch back to a stack that's 99% identical. Cooperative multitasking was always known to be much more efficient if you could ever get it to work safely - but one misbehaving task killed everything Ironic that with deployment we're moving in the opposite direction - we've decided we really do need the complete isolation of separate VMs/containers and are willing to pay the performance overhead because process separation isn't enough.
ekimekim 10y ago
It's not just about context switching costs. One advantage to non-preemtable concurrency is that data races are much easier to reason about, because any operation that you know won't block becomes atomic by default (this doesn't apply to all models, eg. ones that have m:n scheduling). There's also other resource overheads. For example, I would think nothing of spinning up 10000 greenlets/green threads in python. They cost maybe 1KB of memory each. But spinning up 10000 OS threads? That's a little more dicey.

I've noticed that lots of recent advances in threading are all just ways to avoid context switching of threads and instead handle those switches manually (e.g. "green threads" in Python).

pvg 10y ago

These aren't particularly recent. Java originally had green threads; I think the term itself is from there.

wavesplash 10y ago
Green threads were a thing long before Java.
- pvg 10y ago
  The term, not the variety of threads. I can't find any mention of it pre '95 or so, at least.
  - markkanof 10y ago
    '95, so about when significant amounts of information started being put on the internet?
    - pvg 10y ago
      I'm not so sure about the term 'green threads' but the internet was definitely around well before '95. There doesn't seem to be any mention of 'green threads' in available USENET archives before then, for instance. But if you know of one, anywhere, by all means, I'd love to hear about it.
      - fit2rule 10y ago
        I think MIPS RISC/Os had 'green' threads in the 80's, or I could be mixing it up with Tandem terminology, where Fiber was a constant type, I seem to recall .. either way, the idea of a userspace-managed thread scheme is as old as the hills. The question has always been: who deals out the work, the OS or the App? and as we can see, the question will continue to be asked, and un-answered, probably ad infinitum ..
        pvg 10y ago
        Did it call them 'green threads'? If not, the terminology itself probably doesn't come from there.
        fit2rule 10y ago
        I do remember Tandem and/or Wang talking about green (transportable) threads who were okay to suspend/resume across processor units .. I wish I could find more info, but I really do recall the term being applicable way back when ..
      - markkanof 10y ago
        What I was getting at was that around '95 was when the internet was really starting to come into generalized usage and exponentially more information published on the internet at that time than before. So maybe an internet search wouldn't turn up results, not because the term wasn't in existence prior to '95 but because the term wasn't published on the internet prior to '95.
- polskibus 10y ago
  Erlang had green threads from the very beginning, in the 80s.
  - pvg 10y ago
    Erlang processes aren't threads and aren't called 'green' so I don't see how the term itself could have originated there.
dragonwriter 10y ago
Wikipedia agrees with you on the source of the term. Both the M:N and N:1 threading models themselves are older than Java, but the term "green threads" seems to have come from there.
- pvg 10y ago
  Oh I didn't notice the wikipedia thing was actually sourced. I think that pretty much settles it. http://web.archive.org/web/20080530073139/http://java.sun.com/features/1998/05/birthday.html http://web.archive.org/web/20080530073139/http://java.sun.co...

lmm 10y ago

OS-level threads are a crude big hammer way of doing parallelism - want to run a task? Just switch out the whole 8kb of stack, then switch back to a stack that's 99% identical. Cooperative multitasking was always known to be much more efficient if you could ever get it to work safely - but one misbehaving task killed everything Ironic that with deployment we're moving in the opposite direction - we've decided we really do need the complete isolation of separate VMs/containers and are willing to pay the performance overhead because process separation isn't enough.

ekimekim 10y ago

It's not just about context switching costs. One advantage to non-preemtable concurrency is that data races are much easier to reason about, because any operation that you know won't block becomes atomic by default (this doesn't apply to all models, eg. ones that have m:n scheduling). There's also other resource overheads. For example, I would think nothing of spinning up 10000 greenlets/green threads in python. They cost maybe 1KB of memory each. But spinning up 10000 OS threads? That's a little more dicey.