Before looking at the Go scheduler time, we need to understand why you need it, because we might think, OS kernel is not already a thread scheduler Well?
POSIX API familiar people know, POSIX programs in largely a Unix process model approach is a logical description and extension, both have many similarities. Thread has its own signal mask, CPU affinity and so on. But many features of the Go program for both cumbersome. Particular context context switch time-consuming. Another reason is that Go's garbage collection need all goroutine stopped so that the memory in a consistent state. Garbage collection point in time is uncertain, if the OS relies on its own scheduler to schedule, then there will be a large number of threads need to stop working.
GO was a separate development scheduler can know when its memory state is the same, that is to say, when we start collecting garbage, running just have to wait for that thread to run on nuclear was on CPU, rather than waiting for all threads. A mapping relationship between user space and kernel space thread has thread: N: 1,1: 1 and M: N. N: 1 is that multiple (N) user threads always run in a kernel thread, context context switch really fast, but not the real advantage of multicore. 1: 1 is that a user thread to run only on a kernel thread, then you can take advantage of multi-core, but very slow context switch. M: N is to say, goroutine multiple threads to run on multiple cores, this appears to be an assembly of the above advantages of both, but will increase the difficulty of scheduling.
Go inside the scheduler has three important structural: M, P, G
M: represents the real OS kernel threads, and POSIX thread in the almost real working people
G: represents a goroutine, it has its own stack, instruction pointer and other information (waiting channel, etc.), for scheduling.
P: scheduling on behalf of the context, it can be seen as a local scheduler, so go to run the code on a thread, which is achieved from the N: 1 to N: M key mapping.
FIG seen, there are two M physical threads, each M has a context (P), each also have a goroutine running.
The number of P can be set by GOMAXPROCS (), which in fact it represents a real degree of concurrency, ie how many goroutine can run simultaneously. Goroutine gray figure who did not run, but ready for the ready state, we are waiting to be scheduled. P maintains the queue (called runqueue), Go language, start a goroutine is easy: go function on the line, so have a go each statement is executed, runqueue joined a queue goroutine at the end of its next scheduling point, remove it (how to decide which to take goroutine?) from runqueue in a goroutine execution.
Why maintain multiple contexts P? Because the OS when a thread is blocked, P may instead defected to another OS thread! We see the figure, when an OS thread are clogging M0, P instead run on OS thread M1. The scheduler to ensure there is enough threads to run all the context P.
M1 figure may have been created, or removed from the thread cache. When the MO returns, it must try to get a context P goroutine to run, under normal circumstances, it would be from other OS threads where steal steal a context here, if I did not steal it, put it on a global runqueue in goroutine and then went to bed himself a great sleep (into the thread cache). Contexts are also periodically check the global runqueue, otherwise goroutine on global runqueue never executed.
Another case is assigned the task P G finished quickly performed (uneven distribution), which leads to a context P dryness system idle all right, but any course busy. But if there is no global runqueue task G, then P would have to pick up some other context G from P to perform there. In general, if the context from another context P P there to steal a task, then, generally 'steal' run half of the queue, which ensures that each OS thread can fully use.
