4 ms·

Very interesting article and analysis, although it would be nice if it explained what exactly a "Green Thread" is. From the article, I am guessing that a "Green

Very interesting article and analysis, although it would be nice if it explained what exactly a "Green Thread" is. From the article, I am guessing that a "Green Thread" is related to the lightweight low-level concurrency mechanism that he is referring to as the alternative to normal threads, but it is not exactly clear what that really means.

noelwelsh 12y ago
A green thread is a "lightweight" thread, meaning a thread that is managed by a user level process, not by the OS. This main advantage is you avoid OS thread context switch time, which is comparatively very large. The disadvantages are: - you have to balance load across true OS threads to take advantage of multiple CPUs. (You often pin an OS thread per CPU.) - if you make a call to a blocking OS function you have no way to pre-empt your lightweight thread. HTH. Update: "you have to balance load" --> I mean the green thread library implementer. Users of a lightweight threading library typically don't concern themselves with this, though they might if performance becomes an issue.
- MCRed 12y ago
  Neither of those disadvantages exist in the erlang system, as the scheduler spreads processes across OS processes. I can't speak for "Actor Model" libraries, though.
  - Cr8 12y ago
    Sure they do. Erlang spreads processes across OS threads, like most other green-threading impls, and its not always great at it. (I don't know what you mean by "across OS processes." Processes on different Erlang VMs can communicate but the scheduler isn't going to move processes between them) Calling into native code isn't an easy problem in Erlang either. NIF calls will block a scheduler thread, but the scheduler knows nothing about how long a NIF call is expected to take and will happily queue up processes to be run on a thread that is blocked inside a NIF call. "Regular" erlang I/O is done by queueing up requests to be fulfilled by .. you guessed it, a pool of threads that spend most of their time sleeping in blocking i/o calls.
- otterley 12y ago
  What's old is new again? http://en.wikipedia.org/wiki/Green_threads#Green_threads_in_the_Java_virtual_machine http://en.wikipedia.org/wiki/Green_threads#Green_threads_in_...
  - noelwelsh 12y ago
    Yes, in some ways. Usually you get a new concurrency model in addition to a new threading model, and more control than the original JVM green threads gave you.

noelwelsh 12y ago

A green thread is a "lightweight" thread, meaning a thread that is managed by a user level process, not by the OS. This main advantage is you avoid OS thread context switch time, which is comparatively very large. The disadvantages are: - you have to balance load across true OS threads to take advantage of multiple CPUs. (You often pin an OS thread per CPU.) - if you make a call to a blocking OS function you have no way to pre-empt your lightweight thread. HTH. Update: "you have to balance load" --> I mean the green thread library implementer. Users of a lightweight threading library typically don't concern themselves with this, though they might if performance becomes an issue.

MCRed 12y ago
Neither of those disadvantages exist in the erlang system, as the scheduler spreads processes across OS processes. I can't speak for "Actor Model" libraries, though.
- Cr8 12y ago
  Sure they do. Erlang spreads processes across OS threads, like most other green-threading impls, and its not always great at it. (I don't know what you mean by "across OS processes." Processes on different Erlang VMs can communicate but the scheduler isn't going to move processes between them) Calling into native code isn't an easy problem in Erlang either. NIF calls will block a scheduler thread, but the scheduler knows nothing about how long a NIF call is expected to take and will happily queue up processes to be run on a thread that is blocked inside a NIF call. "Regular" erlang I/O is done by queueing up requests to be fulfilled by .. you guessed it, a pool of threads that spend most of their time sleeping in blocking i/o calls.
otterley 12y ago
What's old is new again? http://en.wikipedia.org/wiki/Green_threads#Green_threads_in_the_Java_virtual_machine http://en.wikipedia.org/wiki/Green_threads#Green_threads_in_...
- noelwelsh 12y ago
  Yes, in some ways. Usually you get a new concurrency model in addition to a new threading model, and more control than the original JVM green threads gave you.