Goroutine Scheduling Model conjecture

This is a creation in Article, where the information may have evolved or changed.

Objective

In the recent study of the Go language, one of the major features of the go language is the support for Coroutine, a user-level thread. By running in the user-state program implementation of the "execution" of the scheduling and switching (this paper will be a concurrent execution of a logical unit called "Executor"), the entire process runs on one or more threads, the execution of the body switching process without "trapped" kernel state, so lighter.

This approach also has some shortcomings, because the concept of the Association of the early, mainstream language has not provided support, there must be a reason, this we will discuss later.

Of course, in order to better understand goroutine, we need to talk about the implementation of Goroutine scheduling model. However, the author is a Java developer, the analysis of C and the compilation of the source of things such as limited ability, although there are many references and open source code, analysis to analyze, I was drunk. So after looking at some Goroutine scheduler data, this article from another point of view, describe the next simple scheduling model how to implement. The final analysis may not be consistent with the actual implementation of Goroutine, but also hope that we forgive.

A scheduling model for a single-threaded process

Assuming that there is only one thread that runs a dispatcher, the scheduler takes an executor from its managed collection of executions to the thread execution. The thread executes the following logic:

If you consider the various abnormal exit situations of the execution body:

Thus we can determine that the implementation of this thread logic requires two abstractions: the execution body and the scheduler.

• Execution Body contains: context of the execution body, execution logic, etc.
  
• Scheduler: Execution body set (linked list), actuator switching, etc.

The model has two problems:

• The executing body will always "occupy" the thread unless the execution is complete, an active discard, or a call to the system. The scheduler can only look at it because it has no "occupy" threads. This non-preemptive approach is a common problem in the co-scheduling model.
  
• A new executor may be added to a collection of execution bodies during execution, causing the thread to incur excessive burden.

Scheduling Models on multiple threads

As you can imagine, if you just run on a thread, then Goroutine is too simple, and then talk about running on multiple threads.

Whether it's running on a few threads, the thread has to start with one, and it's the first thread that runs the logic. Of course, before the first thread starts, it is certain to do some initialization work for the entire scheduling model.

There is a big difference between scheduling on multiple threads and scheduling a single thread: Once the execution of the body list contains too many executions, you need to open a new thread and transfer some of the execution. Conversely, if a thread executes a list of empty bodies, it needs to "dig" the execution from the global list or other thread.

The executing body itself is stateful.

• Take the initiative to abandon execution. Sets the execution body to the runnable state and then into the global execution body collection. (It appears that the executing body is actively abandoning execution, not only to abandon the execution opportunity of the thread, but not to continue to stay on the threads)
  
• Channel operations and network operations. The executor is placed in the wating state, stripped from the collection of execution bodies of this thread until its dependent conditions are met.
  
• Invokes a system call.

Once the first thread starts executing, the GO dispatch model also creates a Sysmon thread (responsible for monitoring, not running the execution) and the problem is that the entire thread is blocked once the system call is called in the execution body. In order not to affect the execution of other execution in the thread, the go language is the system call of its own encapsulation, so when the encapsulation system calls, can do a lot of hands and feet, that is, when entering the system call execution Entersyscall, exit and execute Exitsyscall function. Entersyscall the execution body from the current list of execution bodies and changes the state of P to Syscall. Sysmon Monitoring thread will scan all the P, found a p in the state of Syscall, it is known that the P encountered the execution of the system call, so the system monitoring thread will create a new thread to the syscall of the p to rob, began to work, This way the other actuators in the car can bypass the previous system call waiting. The thread that was robbed p and other system calls returned, found that their p is gone, can not continue to work, so can only execute the system call the execution body put back to the global list, and go to sleep.

Four abstractions of the Goroutine scheduling model

With the above cushion, we look at the Goroutine scheduling Model 4 important structures, respectively, M, G, P, Sched, the first three are defined in Runtime.h, Sched defined in PROC.C.

• The SCHED structure is the scheduler, which maintains queues with storage M and g (which may be global), as well as some state information of the scheduler.
  
• M is a kernel-level thread, an M is a thread, Goroutine is running above M, and M is a large structure that maintains a lot of information such as the small Object memory cache (Mcache), the currently executing goroutine, the random number generator, and so on.
  
• P Full name is processor, the processor, its main purpose is to perform goroutine, so it also maintains a goroutine queue, which stores all the goroutine that need it to execute.
  
• G is the goroutine implementation of the core structure, g maintenance of the goroutine required stack, program counter and its location m and other information.

It's better to talk about it from the front to the back.

Reference documents

Goroutine and Scheduler