|This article needs additional citations for verification. (March 2016) (Learn how and when to remove this template message)|
In computer programming, green threads are threads that are scheduled by a runtime library or virtual machine (VM) instead of natively by the underlying operating system. 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.
Green threads refers to the name of the Java thread library. The Green Team is the name of the team at Sun Microsystems that designed the Java thread library.
|This section is outdated. (February 2014)|
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.
- Green threads significantly outperform Linux native threads on thread activation and synchronization.
- Linux native threads have slightly better performance on I/O and context switching operations.
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 spawn specific I/O processes (hidden to the user) 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 synchronization of blocks of code when it is not necessary.
Green threads in the Java virtual machine
In Java 1.1, green threads were the only threading model used by the JVM, 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 in order to keep the native code to an absolute minimum and to support the migration of its isolates.
Kilim and Quasar are open-source projects which implement green threads on later versions of the JVM by modifying the bytecode produced by the Java compiler (Quasar also supports Kotlin and Clojure).
Green threads in other languages
There are some other programming languages that implement equivalents of green threads instead of native threads. Examples:
- CHICKEN Scheme uses lightweight user-level threads based on first-class continuations
- Common Lisp
- CPython with greenlet, eventlet and gevent, PyPy
- D offers fibers, used for asynchronous I/O as the basis for tasks in the web framework Vibe.d
- Erlang
- Go
- Julia uses green threads for its Tasks.
- Limbo
- Lua uses coroutines for concurrency. Lua 5.2 also offers true C coroutine semantics through the functions lua_yieldk, lua_callk, and lua_pcallk. The CoCo extension allows true C coroutine semantics for Lua 5.1.
- Occam, which prefers the term "process" instead of "thread" due to its origins in communicating sequential processes
- Ruby before version 1.9
- Racket (native threads are also available through Places)
- SML/NJ's implementation of Concurrent ML
- Smalltalk (most dialects: Squeak, VisualWorks, GNU Smalltalk, etc.)
- Stackless Python supports either preemptive multitasking or cooperative multitasking through microthreads (so-called tasklets).
- Tcl has coroutines and an event loop
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 referred to as "green threads", but have significant differences[clarification needed] 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 (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.
Occam is unusual in this list because its original implementation was tied to the Transputer, and hence no virtual machine was necessary. 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 (such as expiring timers, or I/O becoming available). Usually round-robin scheduling is used so that a high-priority process that wakes up regularly will effectively implement time-sharing preemption:
[ [(Delay forMilliseconds: 50) wait] repeat ] forkAt: Processor highIOPriority
Other implementations, e.g. QKS Smalltalk, are always time-sharing. Unlike most green thread implementations, QKS Smalltalk also has support for preventing priority inversion.
- Light-weight process
- Java virtual machine
- Global interpreter lock
- Fiber (computer science)
- GNU Portable Threads
- "Four for the ages". JavaWorld. Retrieved 2009-06-01.
Green threads, the threads provided by the JVM, run at the user level, meaning that the JVM creates and schedules the threads itself. Therefore, the operating system kernel doesn't create or schedule them. Instead, the underlying OS sees the JVM only as one thread. Green threads prove inefficient for a number of reasons. Foremost, green threads cannot take advantage of a multiprocessor system(...) Thus, the JVM threads are bound to run within that single JVM thread that runs inside a single processor.
- "Java Technology: The Early Years". java.sun.com. 2014-12-22. Archived from the original on 2008-05-30.
- "What is the difference between "green" threads and "native" threads?". jguru.com. 2000-09-06. Retrieved 2009-06-01.
On multi-CPU machines, native threads can run more than one thread simultaneously by assigning different threads to different CPUs. Green threads run on only one CPU.
- "Comparative performance evaluation of Java threads for embedded applications: Linux Thread vs. Green Thread". CiteSeerX: 10
.1 .1 .8 .9238.
- Stallings, William (2008). Operating Systems, Internal and Design Principles. New Jersey: Prentice Hall. p. 171. ISBN 9780136006329.
- Praveen, G.; Prof. Vijayrajan (July 2011). "Analysis of Performance in the Virtual Machines Environment" (PDF). International Journal of Advanced Science and Technology 32. Retrieved 2013-01-26.
Also, a thread may block all other threads if performing a blocking I/O operation. To prevent the problem, threads must use asynchronous I/O operations, although the increased complexity can be hidden by implementing separate native I/O processes which cooperate with threads.
- Sieger, Nick (2011-07-22). "Concurrency in JRuby". Engine Yard. Retrieved 2013-01-26.
For systems with large volumes of email, this naive approach may not work well. Native threads carry a bigger initialization cost and memory overhead than green threads, so JRuby normally cannot support more than about 10,000 threads. To work around this, we can use a thread pool
- Goetz, Brian (2005-10-18). "Java theory and practice: Synchronization optimizations in Mustang". IBM. Retrieved 2013-01-26.
- "Java Threads in the Solaris Environment -- Earlier Releases". Oracle Corporation. Retrieved 2013-01-26.
As a result, several problems arose: Java applications could not interoperate with existing MT applications in the Solaris environment, Java threads could not run in parallel on multiprocessors, An MT Java application could not harness true OS concurrency for faster applications on either uniprocessors or multiprocessors. To substantially increase application performance, the green threads library was replaced with native Solaris threads for Java on the Solaris 2.6 platform; this is carried forward on the Solaris 7 and Solaris 8 platforms
- "Threads: Green or Native". SCO Group. Retrieved 2013-01-26.
The performance benefit from using native threads on an MP machine can be dramatic. For example, using an artificial benchmark where Java threads are doing processing independent of each other, there can be a three-fold overall speed improvement on a 4-CPU MP machine
- "Threads: Green or Native". codestyle.org. Retrieved 2013-01-26.
There is a significant processing overhead for the JVM to keep track of thread states and swap between them, so green thread mode has been deprecated and removed from more recent Java implementations
- "kilim/kilim". GitHub. Retrieved 2016-06-09.
- "Kilim". www.malhar.net. Retrieved 2016-06-09.
- "Quasar Code on Github".
- "Parallel Universe". Parallel Universe. Retrieved 6 December 2015.
- "CHICKEN Scheme". Retrieved 6 December 2015.
- "thezerobit/green-threads". GitHub. Retrieved 2016-04-08.
- "Application-level Stackless features — PyPy 4.0.0 documentation". Retrieved 6 December 2015.
- "Racket Places". Retrieved 2011-10-13.
Places enable the development of parallel programs that take advantage of machines with multiple processors, cores, or hardware threads. A place is a parallel task that is effectively a separate instance of the Racket virtual machine.
- "Stackless.com: About Stackless". Retrieved 2008-08-27.
A round robin scheduler is built in. It can be used to schedule tasklets either cooperatively or preemptively.
- "Tcl event loop". Retrieved 6 December 2015.