Green threads

In computer programming, Green threads are threads that are scheduled by a Virtual Machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities. Green threads are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.

Performance

On a multi-core processor, native thread implementations can assign work to multiple processors, whereas green thread implementations cannot. In such an environment, native threads have a sizable advantage. On uniprocessor computers, however, the most efficient model has not yet been clearly determined. [Comparative performance evaluation of Java threads for embedded applications: Linux Thread vs. Green Thread [http://cselab.snu.ac.kr/member/naehyuck/papers/%5BJ14%5DComparative%20performance%20evaluation%20of%20Java%20threads%20for%20embedded%20applications.pdf] ]
Benchmarks on computers running the Linux kernel have shown that:
* green threads outperform Linux native threads on thread activation and synchronization.
* Linux native threads have much better performance on I/O and context switching operations.

Also, a green thread may block all other threads if performing a blocking I/O operation. To avoid that problem, green threads must use asynchronous I/O operations, and that added complexity does increase latency, as well as development time and difficulty.

Being created at the user space level, green threads are lighter than native threads, but as they implement a form of cooperative multitasking, bugs in threaded programs can bring the system to a halt.

Green threads in Java virtual machine

In Java 1.1, green threads were the only threading model used by the JVM. 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 in order to keep the native code to an absolute minimum and to support the migration of its isolates.

Green threads in other virtual machines

There are some other virtual machine languages that still implement equivalents of green threads instead of native threads. For example :
* Ruby [The standard C implementation of Ruby implements threading as green threading [http://spec.ruby-doc.org/wiki/Ruby_Threading] ] however, version 1.9 of Ruby will switch to native threads.
* MzScheme
* Haskell
* Smalltalk (most dialects: Squeak Smalltalk, VisualWorks, GNU Smalltalk, etc.)
* Stackless Python. The normal C implementation of Python supports concurrency through system threads. However, to provide for thread safety, it uses a Global Interpreter Lock which prevent threads to be executed in parallel. [cite web
url=http://www.ddj.com/linux-open-source/206103078?pgno=2
title= Concurrency and Python
publisher=Dr. Dobb's Journal
quote="The GIL is a lock that is used to protect all the critical sections in Python. Hence, even if you have multiple CPUs, only one thread may be doing "pythony" things at a time."
date=2008-02-03
accessdate=2008-07-12] Stackless Python supports either preemptive multitasking or cooperative multitasking through microthreads (so-called "tasklets"). [cite web
url=http://zope.stackless.com/about/sdocument_view
title=Stackless.com: About Stackless
quote="A round robin scheduler is built in. It can be used to schedule tasklets either cooperatively or preemptively."
accessdate=2008-08-27]

The Erlang virtual machine has what might be called 'green processes' - they are like operating system processes (they do not share state like threads do) but are implemented within the Erlang Run Time System (erts). These are sometimes (erroneously) cited as '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 (there is a many-to-many relationship between GHC threads and OS threads), allowing for parallelism on symmetric multiprocessing machines, while not creating more costly OS threads than is necessary to run on the available number of cores.

The Smalltalk virtual machines do not count evaluation steps; however, the VM can still preempt the executing thread on external signals (such as expiring timers, or I/O becoming available). Certain Smalltalk implementations, e.g. QKS Smalltalk, do count evaluation steps, support green threads and prevent priority inversion. In most Smalltalk environments, a high-priority process that wakes up regularly will effectively implement time-sharing preemption:

[ [(Delay forMilliseconds: 50) wait] repeat ] forkAt: Processor highIOPriority

Most green thread implementations do not have any support for preventing priority inversion.

References

ee also

* Light-weight process
* Thread
* Java Virtual Machine
* Global Interpreter Lock

External links

* [http://www.javaworld.com/javaworld/javaqa/2001-04/02-qa-0413-four.html JavaWorld article about Green threads]
* [http://www.codestyle.org/java/faq-Threads.shtml#greenthread Green threads on Java threads FAQ]