Green Threads vs Non Green Threads

Question

I'd like to understand the advantages provided by these type of threads.

• In what environments are green threads better than non-green? Some say green threads are better for multi core processors.

• Any expected behaviour problems.

Holladay

It is extremely unlikely that green threads are better for multi-core processors as it will not use mroe than one core. If green threads are better then you have a program which shouldn't be using threads (sometimes threads are used when they shouldn't be) – Bibcock

Where shouldn't threads be used? – Haver

Answer 1

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.

Shalloon

A thing of the ancient past. Last century. Your professor needs to get up to date. – Jocelynjocelyne

No they where not. SPARC's hardware assisted threading together with Solaris and Java preserves all the features of green threads in the scope of the native threading API. Other versions of Java on the other hand does not get that advantage. The full SPARC+Solaris+Java stack must be used in order to get green threading performance. – Haver

@user1657170: what were they not? What "assisted threading" tech are you mentioning? – Shalloon

Starting with the MAJC processor and SUN practically implemented both native and green threading features in their processors. This also allowed them to implement thread switching on cache misses which cannot be done with software threading. Like green threads this removes the cost of context switching and software thread preemption. Unlike green threads it also enabled all the features of "native" threading. And it also added "vertical threading" which requires that the hardware can switch thread without software involvement. As a result any software threads of any type would be slower. – Haver

@user1657170: what part of what I wrote are you disputing exactly? – Shalloon

You can compare this with graphics. Green threading are like a hand optimized assambly 2D/3D library which any game used to have, because using the OS native capacity for graphics sucked. Then when hardware accelerated graphics came and using the OS API:s suddenly became the fastest option. But only on machines that had hardware accelerated graphics, if that's not there using "native" graphics still suck. – Haver

@user1657170: still don't understand what you're referring to in what I wrote above. Read the article I linked to from ex-Sun, they abandoned green threads around Solaris 2.6. – Shalloon

Most of it and they did not. They abandoned the Java green thread implementation but Solaris still has it in what you call "native threads.", which automatically gets used ny Java when it uses native threads doesn't it? ID software removed 3d from Quake when they made the GLQuake engine. Would you say that 3d in quake is ancient history based on that? – Haver

@user1657170: Fibres (and all the related/similar stuff that has popped up in pretty much all platforms these days, or have essentially been there forever as in Erlang processes) have nothing to do with green threads as the term was used in Java. Of course Sun/Oracle has native threads, and of course the JVM uses them. Again, if you have something specific to point out that is factually wrong in the above, please cite accurate sources. – Shalloon

@Shalloon On: On the contrary I can see not difference between green threads, fibers. Neither in description or implementation. They have vertical threads, a hardware feature, which are something very different from what usually is called native threading - kernel-based SMT. Requiring others to cite "accurate sources" is a bit headstrong when you do nothing of the kind, don’t you think? My reference is the Solaris and SPARC documentation, it's all there. – Haver

What do you call the three links in what I posted above, especially the link to Oracle docs that contradicts what you posted, without reference, on this question? I'm over answering your comments btw, this is a complete waste of time. – Shalloon

Given that the next version of Java now brings back green threading and that all the things I wrote are now mirrored on the OpenJDK website for this project is say that your links contain incorrect and outdated information that not even Oracle agrees with anymore. I already posted statement on why the information in those links are incorrect. Of course incorrect information contradicts correct information. I don't see the why the information in that link, without reference, is any argument against the more up to date information that I provided. – Haver

Answer 2

Green thread memory is allocated from the heap rather than having a stack created for it by the OS. This can potentially give an order of magnitude or more increase in concurrent threads. As other people have mentioned, this would not take advantage of multiple processors automatically, however the use case is typically for blocking I/O -- for example green threads might allow you to handle 100k concurrent connections as opposed to 10k.

So in other words, green threads are better for IO bound operations at a certain scale.

Proudlove

With green threads, you don't really have a 100k concurrent connections. It's only an illusion. – Shults

Technically, the connections would be concurrent, you just can't process their requests concurrently. – Proudlove

The location of the stack doesn't magically cause a speed up. – Jocelynjocelyne

How does green threads make the results of 100k concurrent connection appear on client screens? That's quite an illusion? Could we replicate that having 3d graphics as an illusion on the screen while the code do not produce it? – Haver

Answer 3

Green threads are threads implemented at the application level rather than in the OS. This is usually done when the OS does not provide a thread API, or it doesn't work the way you need.

Thus, the advantage is that you get thread-like functionality at all. The disadvantage is that green threads can't actually use multiple cores.

There were a few early JVMs that used green threads (IIRC the Blackdown JVM port to Linux did), but nowadays all mainstream JVMs use real threads. There may be some embedded JVMs that still use green threads.

Sheritasherj

There are several implementations of green threads that use multiple native threads in order to utilize multi-core or multiprocessor architecture. This include the threading library in .NET and the Quasar library for Java. Both of them use as many native threads as there are cores and use green threads/fibers for additional threads, balancing them between the native threads. – Haver

Answer 4

Green threads are user level threads rather than kernel level threads. They are scheduled by user libraries rather than the kernel. You can have your own scheduling mechanism to schedule threads rather than relying on the OS scheduler.

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

Performace :

On a multi-core processor, native thread implementations can automatically assign work to multiple processors, whereas green thread implementations normally cannot. 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.

Rural

How are all green threads in the process blocked? What if this process has multiple kernel threads and an executor service to dispatch green threads on them? What if the thread doing the syscall simply doesn't get other tasks dispatched to it? Your claim is only true in a single-threaded environment. – Radioactive

What I meant is lets say there are 1 kernel thread for n green threads of a process and 1 green thread makes blocking call (which the single kernel thread handles) then all the green thread corresponding to that kernel thread will get blocked. Obviously this does not hold true for m kernel threads mapped to n green threads for a process. Either case you cannot say it is single threaded environment - depends on kernel thread scheduling. – Rural

Answer 5

Green threads are significantly faster than native threads when having more active threads than processors.

Java initially had support for green threads but unlike most modern green threading implementations it could not scale over multiple processors, making Java unable to utilise multiple cores.

Then Java removed green threading in order to rely only on native threads. That made Java Threads slower than green threads.

Please notice that I am not specifically talking about the Java implementation of green threads which did have disadvantages as it unlike other green thread implications could not scale in a multicore or multiprocessor system.

Haver

Green threads are not significantly faster, if faster at all, for compute intensive tasks. It is a great tool to have for certain tasks though. – Dormeuse

Yes they are. They're not faster at doing calculations but they are faster at threading. They do not offer parallelism like real treads do. Most cases of threading doesn't involve computer intense tasks. Although you might argue that people overuse threads and perhaps should use more state machines and fit what they do into procedural programming. – Haver

There was no context given so please do not assume anything. Given you can run green threads on any number of cpu, just like "ordinary" threads, compute intensive in this case means that no switching will be going on. Since there is no switching, the benefit of using green threads for such purposes is defeated. I am sorry if that was unclear. So no, green threads in the particular scenario I was talking about, does not give you any performance benefits to speak of. – Dormeuse

Answer 6

JAVA Multi-Threading is implemented by two models:

1. Green Thread Model
2. Native OS Model

Green Thread Model: The Thread which is managed by JVM, without taking underlying OS support is called Green Thread. Very few OS like Sun Solaris provide support for green thread model. It is deprecated and not recommended to use.

Native OS Model: The Thread which is manged by the JVM with the help of underlying OS is called Native OS Model. All windows OS provide support for native OS model.

Mafala

Answer 7

Green threads aren't scheduled by the OS.

That means that the scheduling for them happens in userspace and is not handled by the kernel. This means that the green threads can't usually be made to use all the CPU cores.

For any mainstream platform running Java these days (eg x86 or x64), you'll be using real threads.

Aggrandize

There is no reason green threads can't utilise multiple CPUs. See, for example, GHC and Go. – Boohoo