On a multi-core processor, native thread implementations can automatically assign work to multiple processors, whereas green thread implementations normally cannot. Green threads can be started much faster on some VMs. On uniprocessor computers, however, the most efficient model has not yet been clearly determined. Benchmarks on computers running the Linux kernel version 2.2 have shown that:
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. To avoid that problem, green threads must use asynchronous I/O operations, although the increased complexity on the user side can be reduced if the virtual machine implementing the green threads spawns specific I/O processes for each I/O operation. There are also mechanisms which allow use of native threads and reduce the overhead of thread activation and synchronization:
Thread pools reduce the cost of spawning a new thread by reusing a limited number of threads.
Languages which use virtual machines and native threads can use escape analysis to avoid synchronizing blocks of code when unneeded.
In Java 1.1, green threads were the only threading model used by the Java virtual machine, at least on Solaris. As green threads have some limitations compared to native threads, subsequent Java versions dropped them in favor of native threads. An exception to this is the Squawk virtual machine, which is a mixture between an operating system for low-power devices and a Java virtual machine. It uses green threads to minimize the use of native code, and to support migrating its isolates. Kilim and Quasar are open-source projects which implement green threads on later versions of the JVM by modifying the Java bytecode produced by the Java compiler.
Green threads in other languages
There are some other programming languages that implement equivalents of green threads instead of native threads. Examples:
Lua uses for concurrency. Lua 5.2 also offers true C coroutine semantics through the functions , , and . The extension allows true C coroutine semantics for Lua 5.1.
The Erlang virtual machine has what might be called green processes – they are like operating system processes but are implemented within the Erlang Run Time System. These are sometimes termed green threads, but have significant differences from standard green threads. In the case of GHC Haskell, a context switch occurs at the first allocation after a configurable timeout. GHC threads are also potentially run on one or more OS threads during their lifetime, allowing for parallelism on symmetric multiprocessing machines, while not creating more costly OS threads than needed to run on the available number of cores. Occam is unusual in this list because its original implementation was made for the Transputer, and hence no virtual machine was needed. Later ports to other processors have introduced a virtual machine modeled on the design of the Transputer, an effective choice because of the low overheads involved. Most Smalltalk virtual machines do not count evaluation steps; however, the VM can still preempt the executing thread on external signals. Usually round-robin scheduling is used so that a high-priority process that wakes up regularly will effectively implement time-sharing preemption: repeat ] forkAt: Processor highIOPriority
Other implementations, e.g., QKS Smalltalk, are always time-sharing. Unlike most green thread implementations, QKS also supports preventing priority inversion.
