22
votes

Green threads were introduced in Erlang and probably all languages based on it know them, also in go (gorutines). Then afaik they were removed from rust.

My questions:

  • How would one implement green threads in .NET? Are there some caveats that prevent current .NET runtime from implementing them?
  • Does it even makes sense in terms of performance? We have a quite lightweight Task and in (near) future we will have even ValueType Task (more suitable for some scenarios)...
2
Erlang and Go don't provide green threads. The term has been mis-used too much to be useful. Fibers have not done well in the age of multi-core, an attempt to add them to NET 2.0 was a failure. Use AppDomain to get the kind of state isolation that Erlang and Go provide. Get light-weight threading from the Task class and the async/await keywords. Look at Akka.NETHans Passant
If you use object pooling to manage tasks and improve performance by caching, you don't need green threads. Poor performance results usually by doing everything async. Mix of async and sync with caching will give you better performance. If green threads were of any great use, I am sure .NET developers would have considered it long ago.Akash Kava
@AkashKava You can get quite good performance from "doing everything async", though the language support must be pretty well designed: joeduffyblog.com/2015/11/19/asynchronous-everythingKyle Strand

2 Answers

1
votes

In computer programming, green threads are threads that are scheduled by a runtime library or virtual machine (VM) instead of natively by the underlying operating system. Managed Threads written with NET Framework will be scheduled by framework but whatever be the case Windows OS will be running beneath and attaching threads to CPU (as NET requires Windows).

0
votes

This is super old but worth pointing out: F# has lightweight user-mode threads built in via MailboxProcessor.