Talk:Green thread

Computing Stub‑class

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Stub	This article has been rated as Stub-class on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.
	This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the `\|auto=` parameter.

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

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. — ^Fatal Error 22:36, 27 January 2009 (UTC)[reply]

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)

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Green?

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

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]