Green Threads VS Non Green Threads

Green Threads vs Non Green Threads

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.

why green threads do not work on multiple cores

I understand native threads can be assigned by OS to multi-cores. Can someone explain that why green threads can not run on multi-cores?

It is my understanding that one of the important goals of green threads is that they are managed completely by the software/VM without operating system intervention. It is the OS that helps "normal" threads fork the virtual processes and run them in parallel on multiple processors. The operating system sees multiple green-threads as a single thread to be scheduled on a single processor.

To quote from the wikipedia definition:

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.

Running in a single processor has some important benefits to green-threads including no cached memory synchronization issues, faster startup, better overall synchronization performance. Most of these benefits are only possible if they are running in the same CPU.

Edit:

There have been lot of discussions about Erlang's and other languages use of multiple processors in their "green thread" implementations. I would argue that even if the word "green" is used by the language to describe these, they violate the classic definition. Certainly the terms are getting muddy but many are describing Erlang's threads as "green processes" to differentiate. They are definitely lightweight but the concepts and definition of "green threads" should not change even when there are overlapping but different implementations. I have yet to find the Erlang documentation describe their threading paradigm as "green".

Here's a number of pages that agree with this assessment:

• Native Vs Green Threads
• Four for the Ages
• Green Vs. Native Threads
• What is the difference between "green" threads and "native" threads?

Green-threads and thread in Python

You can think of greenlets more like cooperative threads. What this means is that there is no scheduler pre-emptively switching between your threads at any given moment - instead your greenlets voluntarily/explicitly give up control to one another at specified points in your code.

Does the GIL affect them? Can there be more than one greenlet running
at a time?

Only one code path is running at a time - the advantage is you have ultimate control over which one that is.

What are the pitfalls of using greenlets or tasklets?

You need to be more careful - a badly written greenlet will not yield control to other greenlets. On the other hand, since you know when a greenlet will context switch, you may be able to get away with not creating locks for shared data-structures.

If I use greenlets, how many of them can a process can handle? (I am wondering because in a single process you can open threads up to umask limit set in your *ix system.)

With regular threads, the more you have the more scheduler overhead you have. Also regular threads still have a relatively high context-switch overhead. Greenlets do not have this overhead associated with them. From the bottle documentation:

Most servers limit the size of their worker pools to a relatively low
number of concurrent threads, due to the high overhead involved in
switching between and creating new threads. While threads are cheap
compared to processes (forks), they are still expensive to create for
each new connection.

The gevent module adds greenlets to the mix. Greenlets behave similar
to traditional threads, but are very cheap to create. A gevent-based
server can spawn thousands of greenlets (one for each connection) with
almost no overhead. Blocking individual greenlets has no impact on the
servers ability to accept new requests. The number of concurrent
connections is virtually unlimited.

There's also some further reading here if you're interested:
http://sdiehl.github.io/gevent-tutorial/

Green threads and Native threads in java

What is the difference between green and native threads?

Green threads are scheduled by a virtual machine.

Native threads are scheduled by a operational system.

Why does it named as green and native?

"Green" is earlier JVM threads project code-name. It is name of library, which provided VM-sheduled threads in Java 1.1

Native threads called so because they're belong to native platform.

How do we know that created thread is native or green?

Green threads are in past, JVMs work only with native threads since 1.3

"Green threads" refers to a model in which the Java virtual machine
itself creates, manages, and context switches all Java threads within
one operating system process. No operating system threads library is
used.

"Native threads" refers to a in which the Java virtual machine creates
and manages Java threads using the operating system threads library -
named libthread on UnixWare - and each Java thread is mapped to one
threads library thread.

What's the difference between green threads and Erlang's processes?

Green Threads can share data memory amongst themselves directly (although synchronization is required of course).

Erlang doesn't use "Green Threads" but rather something closer to "Green Processes": processes do not share data memory directly but do so by "copying" it (i.e. having independent copies of the source data).

---

Related Topics