why green threads do not work on multiple cores

Question

On wikipedia: Green_threads is described as normally cannot run on multi-cores without explaining why.

On a multi-core processor, native thread implementations can automatically assign work to multiple processors, whereas green thread implementations normally cannot.

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? Is it because green threads are derived/spawned from native threads, they cannot be moved from on native thread to another?

Amazement

Answer 1

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?

Zannini

The downvotes are simple. You're wrong. Your answer is misleading. That's pretty much the entire POINT of the downvoting system. – Locoweed

Answer 2

The simple answer is: Wikipedia is wrong / inconsistent. Green threads can make use of M:N threading. Notably, this is how Erlang works. (I don't have a reference for this, but it shows up in most discussions of the VM.)

If you were being a language lawyer, then you could say that this doesn't happen "automatically". The green thread implementation has to take care of scheduling green threads on multiple native threads, instead of the operating system doing this implicitly. That said, the greater point remains, which is that it's very much possible for green threads to execute in parallel on a multicore system.

Devotional

To quote the wikipedia page: "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 from standard green threads." – Zannini

I don't. You are commenting that the wikipedia page is "wrong". I'm just saying that the page specifically addresses the Erlang threads as being non-standard in terms of software green-threads. – Zannini

@Zannini Sorry, it just reads like making an arbitrary distinction to me. In the absence of a definition of what "standard" is, or what those difference are and why they matter, the statement you quoted is essentially "they're different because they are". – Devotional

I'd say that wikipedia is defining green threads as being single CPU and that the Erlang threads are non-standard. If you want to provide an alternative source as a definition then fine but otherwise you are just disagreeing with their definition. – Zannini

guys, the green threads I mentione is pretty much like python green threads spawned from eventlet libarary. Let's not go near Erlang 's case here. – Amazement

@Zannini No, my position is that there is no single cut-and-dry definition of a green thread versus a native thread, or between a thread and a process. It's just a bunch of possible architectural decisions: share-everything by default vs. share-nothing by default vs. never share data; what the mapping of user-space entities to kernel-space entities is (i.e. are one multiplexed to the other). The only thing that makes a "green thread" unable to take advantage of SMP is that the green thread library doesn't implement this capacity. – Devotional

@Amazement Then you should ask about that specific library and its capabilities. If you're asking about a general concept that can be implemented in several equally valid ways, then of course the answer will be "it depends". – Devotional

That's just not true @millimoose. One of the basic architectural differences with green threads is that they don't have the memory synchronization issues inherent in a multiple-CPU configuration. It's part of the definition. Hence erlang being "special". – Zannini

This answer is correct. Green threads can be and are used with Multiple processors. They can even be migrated between processes. Other examples (in addition to Erlang) include Haskell and Mercury. – Mithridate

In addition to the already-mentioned Erlang, Haskell and Mercury we can add several Prolog implementations. Wikipedia and Gray are just plain wrong. – Locoweed

Upon revisiting I think the issue here is the non-equivalent qualities of "scheduled by the VM, not the OS" and "implemented without relying on native OS capabilities". You can certainly implement a threading library scheduled in user space by using native OS parallelism features when they're available, without actually relying on them. (So, for example a M:N model implementation will just make N=1 if the underlying OS doesn't support parallelism.) Whether you call those "green" I've no idea, I just wanted to point out that these qualities are distinct. – Devotional

I think that the definition of "green threads" is started to get muddy. I would argue that the languages that are scheduling to multiple processors deviate from the definition. For example, Erlangs threads are often called "green processes" @JUSTMYcorrectOPINION. Also, if you downvote someone, it is polite to at least leave a comment. – Zannini

Can you provide some references to support your opinion that those languages' thread paradigms are "greeN" @JUSTMYcorrectOPINION? – Zannini

Looking at the Talk section of that page, it does seem to be a factual error which was supposed to be removed. en.wikipedia.org/wiki/Talk:Green_threads#Multicore.2FSMP, it was also noted as being wrong towards the end of this: en.wikipedia.org/wiki/… – Annul