Is there a difference between corroding, fiber and green threads?

Asked

Viewed 46 times

4

According to the title of the question, I see these names being used to describe very similar things.

In the Python world we have Greenlets described as corroding and Green Threads. In the Java world we have the project Loom introducing fibers. In the world Kotlin we have corrotinas and libraries as Quasar (Ron Pressler’s current Loom Project leader project) which, among other things also implements fibers.

All these constructions seem to touch the same points and arrive at the same end result. Asynchronicity and multitasking cooperative that works in user mode.

Are we all talking about the same thing? Or are there conceptual differences between Corrotins, Fibers and Green Threads? If there are conceptual differences, can we implement one thing through the other? (e.g., we can implement Green Threads and Fibers using corrosive?).

asynchronous competition
  • 2

    PS: I’m creating some questions for the community. Initially I have no intention of answering my own questions (but I may do so if the questions do not attract good answers). Please do not be shy, the whole idea is to create good questions so that you can answer :).

  • 1

    Another gift for the community :) I know that Java has had Green Threads (I don’t know if it was the same concept and intention, it is often given the same name for different concepts) and in Ruby there is also some old construct in this line. Awaiting one of those well-informed answers :) P.S.: I know of a Turing who has a good one spoiler for the last question :)

1 answer

0

I see green threads and fibers as something a little more "ancient" than corollaries. When operating systems started supporting threads, a thread cost almost equal to a process.

There was then an interest in getting the advantages of threads, but without the associated costs, trying to keep the most of the thread implementation out of the kernel. The n:m threading model consisted of mapping "n" light threads to "m" operating system threads, where n>m.

Over time, it has been discovered that threads are not panacea, which make development and debugging much more complicated. Operating system developers have also noted that implementing n:m threading is complicated; Linux has always been 1:1. On the other hand, they found more efficient ways to implement kernel threads, even on the x86 platform, which removed the motivation of the n:m scheme.

The point is perhaps that green threads would be a concept closer to the operating system, while corollaries are tied to the language.

Browser other questions tagged asynchronous competition

You are not signed in. Login or sign up in order to post.