Talk:Green thread

Inefficiency

"As Green Threads are highly inefficient compared to native threading"

Why are green threads inefficient? It seems to me that they have the potential to be more efficient since no system-level calls need to be made.—C45207 | Talk 19:39, 29 April 2007 (UTC)

I agree that the sentence was not backed by facts (and slightly false). I changed it a little and added a paragraph on Green Threads performance. Hervegirod 21:19, 29 April 2007 (UTC)

My experience is that it's much easier to implement a green threads system since you can make sure that inter-thread yields happen at sane times. On the other hand, native threads win massively when you have more than one processor (which is becoming ever more common these days) since they can fully utilize the system's resources. Donal Fellows 14:42, 15 September 2007 (UTC)

"Asynchronous I/O increases Latency" - it does? Can this be sourced? Asynchronous_I/O in fact states that it used to improve (ie decrease) latency. —Preceding unsigned comment added by 82.210.249.81 (talk) 15:59, 3 November 2008 (UTC)

It wasn't referring to the I/O operations themselves, but to the "added complexity" that comes with them. I don't know how true this is though. — ^FatalError 22:36, 27 January 2009 (UTC)

The *details* matter as to what is more efficient. Lots of native threads running on a few CPU cores means the OS spends much of time context switching, and CPU caches aren't as useful as the same thread may switch between CPUs. See http://www.kegel.com/c10k.html (If you use the best native methods, eg overlapped IO if Windows you often get much better performance with many green threads stacked on a few native threads) —Preceding unsigned comment added by 142.179.200.17 (talk) 19:42, 14 May 2009 (UTC)

Capitalization

The terms "thread", "native Thread", and "Green Thread" seem to have inconsistent capitalization throughout this article. Does anyone know of any official capitalization scheme for these words? Otherwise, we should just have either them all title-cased or all lowercase. michaelb ^{Talk to this user} 15:04, 31 May 2007 (UTC)

No, it seems like every link had a capital letter. I reorganized the linking in the entire article to make it more efficient. Here are the mistakes: (User:PGSONIC, continued in next section)

I've made them all lower-case. I consider them to be common noun phrases, similar to terms like "dog door" and "washing machine".—C45207 | Talk 22:28, 25 June 2007 (UTC)

Link problems

I just fixed the following problems in links:

• Capitalization of every Hyperlink is not necessary and looks Grammatically dumb. Hypertext and hypertext will not take you to different places (although HYPERTEXT will).
• Wiki has support for attaching suffixes to the end of link names like so: [[attach]]ing. There is no reason to do this: [[attach|attaching]].
• You only need to link to the same link once per article. If you link to the same place more than once, you'll overload the amount of links.
• Common abbreviations like I/O are already supported. There was no reason to do this: [[Input/output|I/O]]

- PGSONIC 17:54, 24 June 2007 (UTC) PS - This carries on from my previous comment. - PGSONIC 17:58, 24 June 2007 (UTC)

Pseudo Threads

Where is the difference between Green Threads and Pseudo Threads, an established term? -- 84.132.248.179 13:32, 12 July 2007 (UTC)

The difference is in the implementation details. Green Threads are specific to "write once, run anywhere" languages like Java and Ruby. They are implemented in cooperative multitasking. On the other hand, "pseudothread" is very general; meaning any form of implementation. - PGSONIC 02:39, 10 August 2007 (UTC)

Green?

Why are they called green threads? --Mdg149 14:09, 31 August 2007 (UTC)

Yes, why??? 84.9.92.9 (talk) 11:08, 20 June 2008 (UTC)

I always assumed it was "green" as in neive/inexperianced but i've never seen any official expalantion. Plugwash (talk) 20:38, 27 January 2009 (UTC)

I think the name comes from Java; other languages call them differently. -- intgr [talk] 14:10, 5 May 2009 (UTC)

I believe the name comes from the fact that, in the United States, if you aren't a NATIVE, then you likely carry a GREEN card. So non-native threads are green threads. 71.198.23.108 (talk) —Preceding undated comment added 07:22, 4 June 2009 (UTC).

I recall the term from no later than 1975 when at some computing conference someone illustrated the difference between the two sorts of threads and used green chalk to draw the data structures that support Green Threads. NormHardy (talk) 01:23, 14 April 2015 (UTC)

Coroutine?

The definition of Green Threads seems identical to the historic definition of Coroutines. Only if you insist that a Coroutine cannot suspend in a subroutine (i.e. suspend when there is call stack or context) would there be any difference.

The term Green Thread is quite "new". Coroutines in Simula (and early C++ versions) worked exactly like Green Threads. DRW - Oct 8, 2007 —Preceding unsigned comment added by 207.59.232.138 (talk) 15:53, 8 October 2007 (UTC)

I'd say that the difference between Green Threads and coroutines is that the latter usually has an explicit yielding mechanism, no? Whereas Green Threads is something that is part of the implementation of a virtual machine, making it appear as if there were pre-emptive threads to the program running inside the virtual machine. Pphaneuf 18:54, 28 October 2007 (UTC)

Factual errors

Ruby

Ruby doesn't have green threads. Ruby has threads, whether those threads are implemented as green threads or native threads is left to the specific implementation – many implementations (YARV, JRuby, XRuby, Ruby.NET, IronRuby) actually use native threads.

Also, Ruby 2.0 doesn't exist. Ruby 1.9 hasn't even been released yet, Ruby 2.0 hasn't even been planned yet. jwmittag (talk) 00:07, 12 September 2008 (UTC)

hmm as there is no specification for Ruby, Ruby MRI reference implementation being the de facto specification, I think we can assume that Ruby really uses green threads. Leaving that to the various implementations would required a spec of some sort, which is not the case for now. All other implementations try to stick to MRI's behavior, but it is sometimes much more difficult to implement green threads MRI's way than to use native threads already provided by the JVM, CLR, etc... But you are right about 2.0. I think I fixed the text. Hervegirod (talk) 00:20, 12 September 2008 (UTC)

Multicore/SMP

It is not true that green threads cannot make use of multiple CPU cores. The BEAM Erlang VM implements SMP/multicore scheduling for its green processes and there is no reason, why that same scheme would not work for green threads. The Rubinius Ruby VM is maybe going to implement such a scheme in the future. jwmittag (talk) 00:07, 12 September 2008 (UTC)

You maybe right, but Erlang is built from the ground-up for concurrent programming, so what is easy to do in a language designed specifically for concurrent processing might be more difficult in other languages. Hervegirod (talk) 00:28, 12 September 2008 (UTC)

That doesn't make the statement any more true. jwittag is right, this is a false statement—I'm removing it. — ^FatalError 02:05, 1 June 2009 (UTC)

Green threads in CPython

{{As a matter of fact, CPython uses true POSIX threads at least for UNIX OS. I don't know what it is for other OS so I'll let an expert edit it — Preceding unsigned comment added by 129.199.21.102 (talk) 11:14, 11 April 2018 (UTC) }} I'm sorry, from the format of the article I first thought that it implied that "CPython uses only green threads" which would have been wrong, but I mis-understood that it "implements" green threads, my bad --129.199.21.102 (talk) 11:26, 11 April 2018 (UTC)

Green threads in Java

The section called "Green threads in Java virtual machine" conflates Java with the Java virtual machine implementation. The Java specification doesn't specify how threads should be implemented; in fact, it specifically says, "These semantics do not prescribe how a multithreaded program should be executed. Rather, they describe the behaviors that multithreaded programs are allowed to exhibit. Any execution strategy that generates only allowed behaviors is an acceptable execution strategy." The Sun implementation stopped using green threads in version 1.1, but other JVMs may not have. For example, Jikes RVM still uses green threads. Afty (talk) 17:21, 6 November 2008 (UTC)

I don't know if we should replace Java by Sun's JVM. The Java Memory Model (cf. your reference) says that These threads independently execute code that operates on values and objects residing in a shared main memory. Threads may be supported by having many hardware processors, by time-slicing a single hardware processor, or by time-slicing many hardware processors.. This is not really the case with green threads, it can not be said that Green threads independently execute code, and as the JVM in this case is executing on only one system thread, it is not possible to time-slice more than one hardware processor. So I think that even if the memory model does not "mandate" native threads, it places itself in a native-thread context. The freedom of implementation of the spec does not concern the threading model, but the memory model. See :The memory model describes possible behaviors of a program. An implementation is free to produce any code it likes, as long as all resulting executions of a program produce a result that can be predicted by the memory model(...)This provides a great deal of freedom for the implementor to perform a myriad of code transformations, including the reordering of actions and removal of unnecessary synchronization.. However, I agree that we should mention that some JVMs still implement green threads as of today. Hervegirod (talk) 22:08, 6 November 2008 (UTC)

Green threads in PHP

Can generators actually be considered green threads? I mean if yes, then why Python's coroutines or Ruby's fibers are not mentioned? Pronskiy (talk) 11:49, 14 February 2021 (UTC)

Rust

The article says that "Rust [...] supports green threads through third-party libraries like Tokio". But what Tokio provides is not green threads per the definition at the beginning of the article, it is Async/await.

java green threads

"In Java 1.1, green threads were the only threading model used by the JVM" I'm pretty sure than an old (java 1.0 era) java book I had said that java used green threads on solaris but used native threads on windows. It seems unlikely that they would have changed from native threads TO green threads for java 1.1 . Can anyone source and/or clarify this information. Plugwash (talk) 20:41, 27 January 2009 (UTC)

Fiber

This article would benefit if green thread was differentiated explicitly from Fiber (computer science). This here already gives some background for differentiation. --Abdull (talk) 13:39, 18 September 2009 (UTC)

Deletion: The Performance section of ‘Green Threads’

Claims in the section titled Performance, seemed counterintuitive so it prompted me to check the references. Reviewing cited references, I encountered quite a few factual inaccuracies, and since I was unable to locate a reliable source of performance measurements, I suggest this section be removed until such a time that a verifiable set of information becomes available. Here is the list of problems:

The only reference that provides measured performance information is reference number 3, "Comparative performance evaluation of Java threads for embedded applications: Linux Thread vs. Green Thread" which is an unpublished or a self-published source .

• Reference number 3 states measurement were performed on Linux kernel version 2.2 where this Wikipedia article states the tests were performed on Linux version 2.4.

Here are the software and hardware configurations stated in reference number 3

CPU Motorola MPC 860 50Mhz

Main memory 64 MB SDRAM

Auxiliary memory 8 MB flash memory

Cache memory 4 KB for instruction and

4 KB for data caches

Communication 1 serial port and 1 Ethernet I/F

Display 640x480 color LCD

OS Linux version 2.2.13

Java VM Personal Java version 1.1.3

• These hardware and software configuration are extremely out of date (over 10 years old) and hence irrelevant. OS Linux version 2.2.was released in 2000). Current version of JVM is 1.6

• Foot notes on page 2 of reference 3 states “so we patched the scheduler appropriately to support real-time scheduling.” It is highly unlikely that scheduler in version 2.2 of Linux behaves correctly after such a modification. Nevertheless, since operating system behavior was modified for these measurements the results cannot be generalized as performance results for readily available unpatched versions.

• This article does not specify what standard benchmarks were used for these measurements. Stating “Old benchmarks” is not sufficient.

• The first line under performance section states “On a multi-core processor, native thread implementations can automatically assign work to multiple processors, whereas green thread implementations normally cannot”. This statement is factually incorrect based on the official JVM documentation published by Sun Microsystem: http://java.sun.com/docs/hotspot/threads/threads.html. At least in Solaris there is an OS thread per each JVM thread and these threads are managed by OS.

• Reference 1 is a short article that incidentally contradicts the finding of reference 3 and reference number 2 is a discussion group.

--Balashx (talk) 22:51, 1 May 2011 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Green threads. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://www.webcitation.org/6EDdBO4UG?url=http://zope.stackless.com/about/sdocument_view to http://zope.stackless.com/about/sdocument_view

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:17, 23 October 2017 (UTC)

"Virtual threads" listed at Redirects for discussion

An editor has identified a potential problem with the redirect Virtual threads and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 April 6#Virtual threads until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Robert McClenon (talk) 18:56, 6 April 2022 (UTC)

• A contributor to virtual threads comments on it being "green threads again" on Wikipedia, causing laughter in the audience: https://www.youtube.com/watch?v=WsCJYQDPrrE&t=507s Soc88 (talk) 10:34, 8 February 2024 (UTC)

Green threads subset of virtual threads?

Disputed these are the same per discussion at Wikipedia:Redirects_for_discussion/Log/2022_April_6#Virtual_threads. Djm-leighpark (talk) 08:06, 7 April 2022 (UTC)

• Agreed. Ideally, one would go through Thread, Fiber and Coroutine articles as well and making sure that the core differences are apparent to readers. Soc88 (talk) 10:07, 31 January 2024 (UTC)