
Scheduling in Go: Part II - ingve
https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part2.html
======
the_other_guy
Great article. I am really curious, what's the theoretical position of using
coroutines/green threads vs native OS threads especially in Linux as of 2018?
Was Golang right in choosing this model or Linux has become very efficient
when it comes to creating and scheduling threads?

~~~
pcwalton
It's a tradeoff. You can _sometimes_ get better performance if you implement
scheduling yourself in userland, primarily because you can save a trip through
the OS scheduler when you do context switches. But you lose compatibility with
all existing code if you do so.

It doesn't need to be this way. There is a Linux kernel patch that a Google
engineer gave a presentation about in 2013 [1] that allows for true kernel
threads that can be scheduled in userland, eliminating the tradeoff.
Unfortunately, the patch never seemed to go anywhere, and it seems that the
author is no longer working at Google (mail bounced when I tried to contact
him about it). Note also that Windows already has this functionality, known as
UMS.

[1]:
[https://blog.linuxplumbersconf.org/2013/ocw/system/presentat...](https://blog.linuxplumbersconf.org/2013/ocw/system/presentations/1653/original/LPC%20-%20User%20Threading.pdf)

~~~
twic
2013! This idea dates back to at least 1992, in the form of scheduler
activations, as described in this paper by Tom Anderson (no relation):

[http://web.eecs.umich.edu/~mosharaf/Readings/Scheduler-
Activ...](http://web.eecs.umich.edu/~mosharaf/Readings/Scheduler-
Activations.pdf)

EDIT: And that Google work sounds like directed yields, an old idea which i
traced back as far as 1996 before getting bored:

[https://www.usenix.org/conference/osdi-96/cpu-inheritance-
sc...](https://www.usenix.org/conference/osdi-96/cpu-inheritance-scheduling)

~~~
romed
I don't think anyone from google claims that threads with userspace switch-to
scheduling is a novel advancement of computer science. However, it is somewhat
novel to have a production-quality implementation of same in C++.

------
lostmsu
The sad part of the story is that now we have yet another language, that lived
off hype without bringing anything new to the table.

BTW, TL;DR; is: Go uses per thread task queues with stealing, and an
additional global one.

~~~
weberc2
I don’t know. I appreciate having a simple language that lets me get things
done quickly and mostly stays out of my way. Not just the type system or even
the runtime mind you, but the ecosystem and tooling as well.

~~~
lostmsu
Hm, what did you switch from, that go improved things? Java? .NET?

~~~
weberc2
Those as well as Python, JavaScript, C, and C++.

~~~
lostmsu
Sounds like you actually mostly used Python and JS?

~~~
weberc2
Nope, what gives you that impression?

~~~
lostmsu
The order of words in your message, and the assumption, that you are talking
from experience together with my understanding about the state of tooling for
Java/C# vs those of Go.

