Green threads

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

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.[1]

Etymology

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.[2]

Performance

Lua error in package.lua at line 80: module 'strict' not found. On a multi-core processor, native thread implementations can automatically assign work to multiple processors, whereas green thread implementations normally cannot.[1][3] 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 (long outdated) Linux kernel version 2.2 have shown that:[4]

  • 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.[5] 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.[6]

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[7]
  • Languages which use virtual machines and native threads can use Escape analysis to avoid synchronization of blocks of code when it is not necessary.[8]

Green threads in the Java virtual machine

In Java 1.1, green threads were the only threading model used by the JVM,[9] at least on Solaris. As green threads have some limitations compared to native threads, subsequent Java versions dropped them in favor of native threads.[10][11]

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.

Another is an open-source project called Quasar,[12][13] which adds true green threads (fiber/lightweight threads) to the JVM. Quasar provides a full "lightweight thread" (fiber) abstraction that also encompasses plain threads, so that developers can write, for example a lock that works equally well whether it's accessed by a thread or a fiber.

Green threads in other languages

There are some other programming languages that implement equivalents of green threads instead of native threads. Examples:

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.[citation needed]

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.[citation needed]

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.

See also

References

  1. 1.0 1.1 Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. Lua error in package.lua at line 80: module 'strict' not found.
  10. Lua error in package.lua at line 80: module 'strict' not found.
  11. Lua error in package.lua at line 80: module 'strict' not found.
  12. Lua error in package.lua at line 80: module 'strict' not found.
  13. Lua error in package.lua at line 80: module 'strict' not found.
  14. Lua error in package.lua at line 80: module 'strict' not found.
  15. Lua error in package.lua at line 80: module 'strict' not found.
  16. Lua error in package.lua at line 80: module 'strict' not found.
  17. Lua error in package.lua at line 80: module 'strict' not found.
  18. Lua error in package.lua at line 80: module 'strict' not found.

External links