I'd like to understand the advantages provided by these type of threads.
In what environments are green threads better than non-green? Some say green threads are better for multi core processors.
Any expected behaviour problems.
Green threads are significantly faster than native threads when having more active threads than processors. Java initially had support for green threads but unlike most modern green threading implementations it could not scale over multiple processors, making Java unable to utilise multiple cores.
In computer programming, green threads or virtual threads are threads that are scheduled by a runtime library or virtual machine (VM) instead of natively by the underlying operating system (OS).
Unfortunately, Java does not have built-in support for green threads. Very early versions used green threads instead of native threads as the standard threading model. This changed in Java 1.2, and there has not been any support for it at the JVM level since.
Rust, in fact, has a history with green threads. A green threads runtime used to be the default paradigm for Rust code.
The Wikipedia article Green Threads explains it very well.
Green threads are "user-level threads". They are scheduled by an "ordinary" user-level process, not by the kernel. So they can be used to simulate multi-threading on platforms that don't provide that capability.
In the context of Java specifically, green threads are a thing of the past. See article JDK 1.1 for Solaris Developer's Guide. (It's about Solaris, but the fact that green threads are not used anymore is valid for the usual platforms).
Green threads were abandoned in the Sun JVM for Linux as of the release of version 1.3 (see Java[tm] Technology on the Linux Platform on archive.org). That dates back to 2000. For Solaris, native threads were available from JDK 1.2. That dates back to 1998. I don't even think there ever was a green thread implementation for Windows, but I can't find a reference for that.
There are some exceptions as noted in the Wikipedia article, I gather mostly for low-power (embedded) devices.
Green threads are threads implemented at the application level rather than in the OS. This is usually done when the OS does not provide a thread API, or it doesn't work the way you need.
Thus, the advantage is that you get thread-like functionality at all. The disadvantage is that green threads can't actually use multiple cores.
There were a few early JVMs that used green threads (IIRC the Blackdown JVM port to Linux did), but nowadays all mainstream JVMs use real threads. There may be some embedded JVMs that still use green threads.
Green thread memory is allocated from the heap rather than having a stack created for it by the OS. This can potentially give an order of magnitude or more increase in concurrent threads. As other people have mentioned, this would not take advantage of multiple processors automatically, however the use case is typically for blocking I/O -- for example green threads might allow you to handle 100k concurrent connections as opposed to 10k.
So in other words, green threads are better for IO bound operations at a certain scale.
Green threads are user level threads rather than kernel level threads. They are scheduled by user libraries rather than the kernel. You can have your own scheduling mechanism to schedule threads rather than relying on the OS scheduler.
Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support
Performace :
On a multi-core processor, native thread implementations can automatically assign work to multiple processors, whereas green thread implementations normally cannot. Green threads significantly outperform Linux native threads on thread activation and synchronization.
When a green thread executes a blocking system call, not only is that thread blocked, but all of the threads within the process are blocked.
Green threads are significantly faster than native threads when having more active threads than processors.
Java initially had support for green threads but unlike most modern green threading implementations it could not scale over multiple processors, making Java unable to utilise multiple cores.
Then Java removed green threading in order to rely only on native threads. That made Java Threads slower than green threads.
Please notice that I am not specifically talking about the Java implementation of green threads which did have disadvantages as it unlike other green thread implications could not scale in a multicore or multiprocessor system.
JAVA Multi-Threading is implemented by two models:
Green Thread Model: The Thread which is managed by JVM, without taking underlying OS support is called Green Thread. Very few OS like Sun Solaris provide support for green thread model. It is deprecated and not recommended to use.
Native OS Model: The Thread which is manged by the JVM with the help of underlying OS is called Native OS Model. All windows OS provide support for native OS model.
Green threads aren't scheduled by the OS.
That means that the scheduling for them happens in userspace and is not handled by the kernel. This means that the green threads can't usually be made to use all the CPU cores.
For any mainstream platform running Java these days (eg x86 or x64), you'll be using real threads.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With