It's time for our first actual talk of the day, which is by a very frequent speaker
who I didn't have to look up the introduction of, because every time I look at his talk,
it's like, wow, I learned something very deep about Go.
So, small applause.
Okay, just...
Hello, everybody.
Well, I'm going to talk about the secret life of a Go routine.
This comes from my interest about how Go works internally,
and I was investigating how the Go routine works internally.
So, when I started investigating it, my idea of how Go routines were created
and all that stuff was something like this.
A caring mother with a baby in her arms, taking care of that beautiful, full of joy baby.
It wasn't like that, okay?
I started digging into the code and I realized that it's more like this.
And necromancer racing the deads.
I was like, why? There's a reason for that.
But before that, I'm going to talk about something more general, that is the Go scheduler.
For understanding how the Go routine works, we need to understand how the scheduler works
and how it is shaped.
So, let's start with the different pieces of the Go scheduler.
One of them is the P extract that is the representation of a virtual CPU.
Whenever you say Go Max Prox, what you are saying is the number of pieces that the scheduler has.
And a processor, as I said, is a virtual representation of the CPU.
It can have a status that can be either running, c-scrolling, or g-stop.
It has associated the current M.
We are going to see what an M is in a moment.
Then it has, each processor has a queue of Go routines that needs to be executed.
And a list of free Go routines.
We are going to see what free Go routines are later.
And, of course, other metadata.
This is a very shallow explanation of the scheduler.
This is an over simplification.
Of course, it's more complex than that.
But, well, a lot of other metadata inside the PS track.
Let's talk about the M.
The M is the self-representation of an operating system thread.
It's what is executing your code in the CPU.
And it has associated normally the current Go routine that is running in this M, in this machine.
And the current processor that is associated to this M, that can be null, actually.
There are some cases where the M is not associated to a processor.
But, in general, they are associated.
And other metadata.
Let's talk about, let me, let's talk about the scheduler itself.
On top of all these M's and P's, there's a struct that is called a schedule.
That is, it has all the, it has a list of all the, all the idle M's,
all the M's that are not doing any work,
all the idle P's, processors that have not, that are not doing any work.
All the, at least of global runnable Go routines, a queue of work that is not associated to any specific processor for now.
And a list of global free Go routines.
Okay.
And the start of our show, the Go routine.
There's a struct that is called GStrug.
That struct is, represents a Go routine.
And a Go routine is composed by, in a lot of the stuff, but mainly you have a stack that is a two kilobytes chunk of memory.
The program counter that is similar to the program counter in a thread that is pointing to the next, well, to the current instruction that is executing.
The status of the Go routine that can be running, waiting, runnable.
There's a lot of different statuses.
The current M that is associated to this Go routine is being executed right now.
And the wait reason.
The wait reason is if the Go routine is waiting, they have to be waiting for something.
They have to be a reason for waiting.
And that's the way reason.
There's a lot of other metadata.
But let's take a look at the whole picture.
As I said, we have the scheduler at the top left with a list of free Go routines, a list of runnable Go routines, a list of either processors, either machines.
And we have running processors with running Go routines associated with machines and all that stuff.
Also, another interesting thing is that at global level in the runtime, as global variables, we have a list of all the M's, a list of all the P's,
and a list of all the Go routines.
That really are three global variables in the runtime.
Okay, but how Go routines are created?
This is where the necromancer raising the dead's metaphor comes into place.
Because whenever you create a Go routine with just Peggy's, you create a spawn a new Go routine and start running things on that.
But that's not what is happening.
There's two ways of creating a Go routine.
One option is to create it from scratch and the other option is to reuse all Go routine that is no longer working.
So this is what is happening.
Whenever a Go routine finish, it's changed the state to dead.
So all that free Go routines, actually they are dead Go routines.
So whenever you need a new Go routine, you can reuse one of them.
Or the other option, if there's no free Go routine or dead Go routine to reuse, you create a new Go routine full of life, you kill it, and then you raise that from the dead.
So that's the process.
And actually that is how it works in the source code.
It was shocking for me and it was a funny way of representing this.
So let's see an example of that.
Imagine that I have this Go routine here that wants to create a new Go routine.
What it's going to do is pick one of the free Go routines in the free list and raise that from the dead, convert that into a runnable, put that in the queue of the runnable Go routines of the processor,
and call the scheduler and the scheduler is going to, well, and the scheduler is going to eventually execute that Go routine.
Another option is this Go routine here wants to run a new Go routine, spawn a new Go routine, but there's nothing in the free list of the processor.
So it's going to go to the global free list of the scheduler and pick a chunk of them, move them to the processor, and then pick one of them and raise that from the dead and add it to the queue.
And finally you have the option of this one is it wants to create a new Go routine, but there's nothing in the global queue.
So what it's going to do is create a new Go routine.
It's going to kill it and then it's going to raise that from the dead and put in the queue and all that stuff.
So that's how Go routines are created.
Let's see how Go routines, how is the life of a Go routine.
A Go routine can go through a lot of different states, can go to runable to running, from running to waiting, from waiting to runable, from running to preempted, from preempted to waiting.
There's a lot of stuff.
Let's see how, let's see all these transitions one by one.
From runable to running.
That happens when you for example have a Go routine have finished the job or a Go routine start waiting for something.
So it's going to call the scheduler.
So the scheduler is going to try to find another Go routine to execute.
The first thing that is going to do is try to find a Go routine in the local processor, in the runable list of the local processor.
If there's nothing, it's going to go to the global runable queue and it's going to take some of that, it's going to move that work into the processor, it's going to schedule one of that Go routines to be executed.
Then if there's nothing in the global queue, it's going to go to the net pool.
The net pool is this system that allows Go to do IO work in an efficient way.
And what it does is do the IO work and whenever it's finished, it gets the Go routine runable again.
But sometimes what we do is we need to find work to do.
So we go to the net pool and check if something is already done and start executing that.
If there's nothing in the net pool, we are going to steal work from other processors.
And if not, we are going to help the garbage collector in the marked face.
Well, once we have found a Go routine in all the process, we are going to mark that as running and we are going to assign the machine, the operating system thread to that Go routine.
We are going to mark that as running and we are going to start executing the code.
Another option is running, well, another change is running to waiting.
One of the interesting part of this is it's exemplifies how Go routines are cooperative entities.
So they cooperate to give you the sensation of concurrency.
So the Go routine, when the Go routine needs to wait for something, is the own Go routine who parks itself.
Whenever I have to write to a channel, for example, if the channel is not buffered and I have to wait for something, what I'm going to do as a Go routine is park myself, stop myself, check my state to waiting, set the wait reason,
detach myself from the operating system thread and run the scheduler.
It's the Go routine that is marking itself as waiting, the one that is calling the scheduler to schedule the new Go routine.
So the scheduler is going to find another task and it's going to start running that.
So what are the reasons why we can wait?
If you go to the Go source code, and actually there's in the bottom right corner, I usually put some references to the Go source code,
but well, if you go to that point in the Go source code, you are going to see the wait reasons and that's the least of all the wait reasons.
There's no more, there's no less. That's all the wait reasons.
Don't pay too much attention to that.
I'm going to summarize that. If you want to take a look, you can go.
But the summary is you have GC reasons, garbage collector reasons,
mutex reasons, semaphore reasons, channel reasons, sleep reasons, and other reasons.
That's mainly why the garbage, why the Go routines waits for something.
Okay, from running to Cisco and to running or runable again.
Well, the Cisco is an interesting part. The Cisco is basically calling the operating system to do something and that can be fast or can be slow.
And for some Cisco, it's kind of obvious, but for some Cisco, it's not so obvious.
So what it does is whenever you enter in a Cisco, whenever you try to execute a Cisco, it's going to detach from the processor
and it's going to detect if the Cisco is slow or fast.
And if it's a fast Cisco, it's going to finish the Cisco and go back directly to running.
But if the Cisco is slow, it's going to just stay in Cisco state
and it's going to detach the processor.
Well, it's going to keep the processor detached so the processor can select another Go routine to execute
and it's going to finish the Cisco eventually and whenever it finish, it's going to move the Go routine to runable again
and then queue that in a processor and all that stuff.
The other thing that is interesting is the copy stack status.
Whenever a Go routine needs to grow the stack because it needs more space for the function parameters
or for the local variables of the function execution, it's passed through this process that it's going to move from running to copy stack.
It's going to reserve the double of the current stack size in memory, copy over all the information from one place to another
and change the pointers and then it's going to move back from copy stack to running again.
From waiting to runable, this is a very interesting case because, again, as I said, Go routines are cooperative.
So normally, a Go routine, it's changed from waiting to runable whenever other Go routine calls go ready.
Whenever other Go routines say to my Go routine that it's ready to keep executing, we are going to see examples of that later.
So whenever Go ready is called, for example, if a Go routine is sending something to a channel and some other Go routine is waiting,
it's going to wake up that Go routine, it's going to mark us ready that Go routine.
Then it's going to mark us ready, it's going to add that to the queue of the processor and try to get a processor to execute that.
Another way is when you reactivate a list of Go routines that happens, for example, when the garbage collector have to reactivate some of the Go routines
and then the garbage collector are waiting for the garbage collector phase, for the mark phase, and when that's finished, it's going to wake up a list of Go routines.
Another case, it's when there's a case where it doesn't need to wait.
Imagine that you say, hey, I'm going to wait for X, but that X is already fulfilled, so I'm going to go back to runable directly.
Another thing is when you are trying to find a Go routine to execute the scheduler, you check the scheduler, sorry, you check the net pool,
and the net pool sometimes has these Go routines that in theory they are waiting, but the data is already there or the job is already done.
So it just moved that app from waiting to runable.
Okay, from running to preempt to waiting or runable.
Go has a preemptive garbage collector, has a preemptive runtime,
and what it does is when a Go routine is executing for too much time, the system monitor is going to detect that and it's going to send a signal to the operating system thread that is executing the Go routine.
That signal is going to mark the Go routine as preempt, so it's going to be moved from running to preempt, and eventually the Go routine itself is going to find the time for moving from preempt to waiting.
And after the next garbage collector scan, it's going to move from waiting to runable again.
So again, this is the whole life cycle, runable, running, syscall, waiting, preempt, govistak.
Now all these states should be more obvious or more clear to everybody.
There are some other kind of similar states of parallel states related to garbage collector.
This is again a bit of a simplification, but this is in general what is the kind of state that you have in the Go routines.
So let's see some examples.
Imagine that you have a channel and you want to send data to that channel.
The channel is not buffered, and there's nobody else waiting for that.
So I try to send the data and because nobody's waiting, I'm going to need to wait for that.
So I'm going to park myself, the Go routine is going to park itself, it's going to add itself to a list of Go routines that is inside the extract of the channel, and it's going to wait there.
So it's there, it's waiting, and eventually another Go routine comes to read from the channel.
What it's going to do is go there, read the data directly from the memory of the other Go routine, and then when it has the data, it's going to call Go ready on that Go routine saying this Go routine is already prepared to keep going.
It's going to, and that's going to end in this state, and eventually the scheduler is going to select that Go routine to be run and everything is going to keep going.
Yeah, this is the whole picture, trying to send the data, waiting inside the channel, getting the data from the other side, and the other Go routine is the one that is responsible of waking up the Go routine that was waiting in the channel.
Let's see another example. Let's talk about the wake groups. For example, I can create a wake group and add three in this case. This is a very common pattern.
And then I just found three Go routines that are going to do certain work in parallel. Then I'm going to wait at that point, maybe one Go routine is already running, maybe not, doesn't matter.
So I call wait, so I'm now waiting. The Go routines keep going, maybe some of them are executed, maybe some of them have finished already, doesn't matter.
Some of them finish and are there. And the last one, the last one is going to call done, the last done, and it's going to see that, hey, the wake group is already zero, so I'm going to call ready on the list of Go routines that are waiting for this wake group.
So that end up with this situation where that's a runnable Go routine that is going to eventually be executed by the, well, that is going to be a schedule by the scheduler, and that's it.
Again, the whole picture here.
Okay, let's talk about how Go routines die. There's a Go routine normally dies when it finished the work. Basically, whenever there's nothing else to execute, it's going to change the state to that, it's going to set most of the data to the zero value, it's going to disconnect the Go routine from the end,
add the Go routine to the free list of the processor, the dead Go routine to the free list of the processor, and call the scheduler to find anything else to execute.
So, yeah, the whole life of the Go routine. Again, if you see this is the scenario where the Go routines are doing things. If I did my job correctly, you now should understand this better.
And also this should sound familiar to. So let me finish with a couple things.
One of them is I want to thanks Laura Pareja, the one that did all the illustrations for this talk. All the illustrations are creative common by.
And you can see the webpage of Laura Pareja. So you can reuse it that do whatever you want with all that images.
Also, I want to, I have a gift from MatterMos that is my company, they're the company that I work for. I have some stickers. I going to left out the stickers there, like Margie said.
So that's exactly right there.
So feel free to pick as many as you want.
But I don't know if, well, I also have some pins too, but they are going to fly probably.
Another thing is what is missing.
I haven't talked about certain things because in the sake of simplicity, I try to avoid getting too much into the details.
One of the things that I removed from the equation and have a lot to do with Go routines is garbage collector.
I ignore the garbage collector entirely and it's a big chunk of how the scheduler interacts and how the Go routines are moving from one stage to another and all that stuff.
The net pool, I mentioned the net pool, but I haven't entered into the details. There's very good talks about the garbage collector and the net pool out there.
I know SIGO. Also, SIGO have certain implications with the Go routines also, but I have ignored them.
The mark assist phase that is kind of important is a relevant part of things that Go routine does, assisting the garbage collector in the mark phase.
This is the monitor that I have mentioned, but I haven't talked in detail about that.
But again, there's talks around system monitor out there.
One of the main references is the Go source code. I totally recommend you to go there and explore it.
There's an illustrated text of Go runtime scheduler that is a YouTube video there.
There's a series of posts from Argonel Labs about the Go scheduler. It's from 2018, so it's not super up today, but the general patterns are still there.
Well, I hope this talk, after this talk, you have a better understanding of how the Go routines work, how the Go routines change from one state to another and all that stuff.
But I want, what is more important to me, I want to encourage you to go there and explore the Go source code because it's a great source of information.
There's a lot of super cool stuff there.
And well, and depending on a combination of your passion about learning and your taste in movies, this can be more exciting than a zombie movie.
So thank you.
If you want to keep in touch with me, feel free to contact me.
And the other thing, if you want to have a follow up session, then try this.
If you want to have a follow up session, asking questions or whatever, feel free to join there.
If you're leaving.
Thank you.