Talk:Green thread

message: "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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
thread_title:  Inefficiency 

message: 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: attaching. There is no reason to do this: 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: I/O
- PGSONIC 17:54, 24 June 2007 (UTC)
thread_title:  Link problems 

message: Where is the difference between Green Threads and Pseudo Threads, an established term? -- 84.132.248.179 13:32, 12 July 2007 (UTC)
replies: text: 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)
thread_title:  Pseudo Threads 

message: Why are they called green threads?  --Mdg149 14:09, 31 August 2007 (UTC)
replies: text: Yes, why??? 84.9.92.9 (talk) 11:08, 20 June 2008 (UTC)
replies: text: 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)
replies: text: I think the name comes from Java; other languages call them differently. -- intgr [talk] 14:10, 5 May 2009 (UTC)
thread_title:  Green? 

message: 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)
thread_title:  Coroutine? 

message: === 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)
replies: text: 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)

text: 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)
replies: text: 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)

text: 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)
thread_title:  Factual errors 

message: 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)
replies: text: 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)
thread_title:  Ruby 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Multicore/SMP 

message: {{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)
thread_title:  Green threads in CPython 

message: 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)
replies: text: 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)
thread_title:  Green threads in Java 

message: 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)
thread_title:  Green threads in PHP 

message: "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)
thread_title:  java green threads 

message: 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)
thread_title:  Fiber 

message: 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)
thread_title:  Deletion: The Performance section of ‘Green Threads’ 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 14:17, 23 October 2017 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  "Virtual threads" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: 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)
thread_title:  Green threads subset of virtual threads?