4 ms·

The two different threading models have different costs/benifits. Native threads are much faster at context switching then green threads, however, native thread

by lgunsch 12y ago

The two different threading models have different costs/benifits. Native threads are much faster at context switching then green threads, however, native threads have a significant startup cost where as spawning green threads is nearly cost-free.

imanaccount247 12y ago
>Native threads are much faster at context switching then green threads No, native threads have a much higher context switch overhead. The downside of green threads is the lack of parallelism, you can only use one CPU core. This is why decent languages multiplex green threads over OS threads (M:N). The mistake rust made was trying to make that distinction transparent.
- lgunsch 12y ago
  Quote from Wikipedia article on Green Threads: "Linux native threads have slightly better performance on I/O and context switching operations." Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not. On top of this, the whole stack is copied upon a context switch.
  - ptx 12y ago
    The paper[1] cited for that quote is specifically about PersonalJava 1.1.3 on Linux 2.2 on PowerPC. It may not be relevant to implementations from this century. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9238&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9...
  - imanaccount247 12y ago
    Your quote lacks the context which makes it clear that it is not a general claim. >Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not Exactly. Native threads have a context switch, green threads don't.
  - SamReidHughes 12y ago
    Wikipedia is wrong and generally speaking you shouldn't trust it on CS matters. Or any other subject, really. Green thread context switching is much faster than native thread switching, as long as you don't do it badly. For example, on Linux, don't use setcontext/swapcontext/etc, because they do a system call to change the signal mask.
- SamReidHughes 12y ago
  Green threads also suck for other reasons. Async file I/O doesn't really work properly on Linux or OS X, so you have to use a thread pool for that, and you can't casually use any other library you'd otherwise want to use, either.
  - imanaccount247 12y ago
    That's why a decent language multiplexes green threads over native threads so you can have your cake and eat it too. You still need the ability to choose to create a green thread or a native thread though, it is the idea of trying to make the two interchangeable that was a problem.
- mietek 12y ago
  Which languages multiplex green threads over OS threads in a non-transparent fashion, exactly?
tomp 12y ago
Actually, green threads are much faster at context switching than native threads. They also consume less heap space for (if it's growable) stack. Native threads are natively supported by the OS, so managing them requires calls to the OS, the main reason why it's slow. However, it comes with a few advantages. The main advantage of native threads is that they are preemptive - they can be scheduled based on ticks (i.e. number of microseconds spent running the thread), even if they are in the middle of a loop. Also, they can be run on different CPUs, the OS takes care of all CPU flags/registers/etc., they are actual OS structures, ...
- MichaelGG 12y ago
  Do other OSes have an equivalent to User Mode Scheduling? It seems to allow you to get the best of both worlds, if your tasks are amenable to the model. http://msdn.microsoft.com/en-us/library/windows/desktop/dd627187(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/dd62...
  - erickt 12y ago
    Google supposedly has implemented something similar called user-level threads, which they talked about at the 2013 Linux Plumbers Conference. If I recall the video correctly, they talk about plans to open source it, but as far as I know there hasn't been much movement in that space yet: http://www.linuxplumbersconf.org/2013/ocw/proposals/1653 http://www.linuxplumbersconf.org/2013/ocw/proposals/1653 https://www.youtube.com/watch?v=KXuZi9aeGTw https://www.youtube.com/watch?v=KXuZi9aeGTw

by lgunsch 12y ago

imanaccount247 12y ago

>Native threads are much faster at context switching then green threads No, native threads have a much higher context switch overhead. The downside of green threads is the lack of parallelism, you can only use one CPU core. This is why decent languages multiplex green threads over OS threads (M:N). The mistake rust made was trying to make that distinction transparent.

lgunsch 12y ago
Quote from Wikipedia article on Green Threads: "Linux native threads have slightly better performance on I/O and context switching operations." Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not. On top of this, the whole stack is copied upon a context switch.
- ptx 12y ago
  The paper[1] cited for that quote is specifically about PersonalJava 1.1.3 on Linux 2.2 on PowerPC. It may not be relevant to implementations from this century. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9238&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9...
- imanaccount247 12y ago
  Your quote lacks the context which makes it clear that it is not a general claim. >Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not Exactly. Native threads have a context switch, green threads don't.
- SamReidHughes 12y ago
  Wikipedia is wrong and generally speaking you shouldn't trust it on CS matters. Or any other subject, really. Green thread context switching is much faster than native thread switching, as long as you don't do it badly. For example, on Linux, don't use setcontext/swapcontext/etc, because they do a system call to change the signal mask.
SamReidHughes 12y ago
Green threads also suck for other reasons. Async file I/O doesn't really work properly on Linux or OS X, so you have to use a thread pool for that, and you can't casually use any other library you'd otherwise want to use, either.
- imanaccount247 12y ago
  That's why a decent language multiplexes green threads over native threads so you can have your cake and eat it too. You still need the ability to choose to create a green thread or a native thread though, it is the idea of trying to make the two interchangeable that was a problem.
mietek 12y ago
Which languages multiplex green threads over OS threads in a non-transparent fashion, exactly?

tomp 12y ago

Actually, green threads are much faster at context switching than native threads. They also consume less heap space for (if it's growable) stack. Native threads are natively supported by the OS, so managing them requires calls to the OS, the main reason why it's slow. However, it comes with a few advantages. The main advantage of native threads is that they are preemptive - they can be scheduled based on ticks (i.e. number of microseconds spent running the thread), even if they are in the middle of a loop. Also, they can be run on different CPUs, the OS takes care of all CPU flags/registers/etc., they are actual OS structures, ...

MichaelGG 12y ago
Do other OSes have an equivalent to User Mode Scheduling? It seems to allow you to get the best of both worlds, if your tasks are amenable to the model. http://msdn.microsoft.com/en-us/library/windows/desktop/dd627187(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/dd62...
- erickt 12y ago
  Google supposedly has implemented something similar called user-level threads, which they talked about at the 2013 Linux Plumbers Conference. If I recall the video correctly, they talk about plans to open source it, but as far as I know there hasn't been much movement in that space yet: http://www.linuxplumbersconf.org/2013/ocw/proposals/1653 http://www.linuxplumbersconf.org/2013/ocw/proposals/1653 https://www.youtube.com/watch?v=KXuZi9aeGTw https://www.youtube.com/watch?v=KXuZi9aeGTw