Anyone have any modern resources on why green threads are considered "better" than OS threads? Presumably the answer has to be deeper than just allocating stack? I would expect that the OS scheduler is generally better at this than the VM (if not why haven't we fixed this?)
-
-
-
This is focused on the cost of context switching, which is entirely costs that live at the scheduler, right? Is there a reason we can't just improve OS/CPU schedulers in the same way?
- 3 more replies
New conversation -
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I don't have any resources but I remember reading in my OS class that user space threads can avoid synchronizing critical sections unlike native threads which saves on time + they don't create kernel managed objects which saves on space (not confident about the last part)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
The best material I’ve found along these lines is about Goroutines, ex- https://blog.nindalf.com/posts/how-goroutines-work/ … More generally, I think the biggest advantage to green threads is that they can take advantage of & work with their context (whatever lang/runtime you’re using)
-
Actually, threads vs greenthreads reminds me of manual managed memory vs GC. - Faster allocation - talking to runtime (instead of OS) - runtime does “magic” to make it work - runtime has more context than OS to optimize for specific use cases
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.