Why does Go have a GMP scheduling model? The following article will introduce to you the reasons why there is a GMP scheduling model in the Go language. I hope it will be helpful to you!

#The GMP scheduling model is the essence of Go. It reasonably solves the efficiency problem of multi-threaded concurrent scheduling coroutines.

What is GMP

First of all, we must understand what each generation of GMP refers to.

• G: The abbreviation of Goroutine refers to coroutine, which runs on a thread.
• M: The abbreviation of Machine, that is, thead, thread, cyclic scheduling coroutine and execution.
• P: The abbreviation of Processor, refers to the processor, which stores coroutines in local queues and provides available coroutines that are not dormant for threads.

Threads M each hold When a processor P wants to obtain a coroutine, it is first obtained from P, so the GMP model diagram is as follows:

The general process is that thread M obtains it from P's queue If the coroutine cannot obtain it, it will compete for the lock from the global queue to obtain it.

Processor P

The coroutine G and thread M structures have been explained in the previous articles. Here we analyze the processor P.

Function

Processor P stores a batch of coroutines, so that thread M can obtain coroutines from them without locking, without having to compete with other threads for the global queue. Coroutine in the process, thereby improving the efficiency of scheduling coroutines.

Source code analysis

The source code of the p structure is in src\runtime\runtime2.go, and some important fields are shown here.

type p struct {
   ...
   m           muintptr   // back-link to associated m (nil if idle)
   // Queue of runnable goroutines. Accessed without lock.
   runqhead uint32
   runqtail uint32
   runq     [256]guintptr
   runnext guintptr
   ...
}

• m is the thread to which the processor p belongs
• runq is a queue that stores coroutines
• runqhead, runqtail represents the head and tail pointers of the queue
• runnext points to the next runnable coroutine

How do thread M and processor P cooperate?

In src\runtime\proc.go, there is a schedule method, which is the first function run by the thread. In this function, the thread needs to obtain a runnable coroutine. The code is as follows:

func schedule() {    
    ...
    // 尋找一個(gè)可運(yùn)行的協(xié)程
    gp, inheritTime, tryWakeP := findRunnable() 
    ...
}

func findRunnable() (gp *g, inheritTime, tryWakeP bool) {
    // 從本地隊(duì)列中獲取協(xié)程
    if gp, inheritTime := runqget(pp); gp != nil {
       return gp, inheritTime, false
    }

    // 本地隊(duì)列拿不到則從全局隊(duì)列中獲取協(xié)程
    if sched.runqsize != 0 {
       lock(&sched.lock)
       gp := globrunqget(pp, 0)
       unlock(&sched.lock)
       if gp != nil {
          return gp, false, false
       }
    }
}

Get the coroutine from the local queue

func runqget(pp *p) (gp *g, inheritTime bool) {
   next := pp.runnext // 隊(duì)列中下一個(gè)可運(yùn)行的協(xié)程
   if next != 0 && pp.runnext.cas(next, 0) {
      return next.ptr(), true
   }
   ...
}

If there is no coroutine in the local queue or the global queue What should I do? Should I just let the thread idle like this?

At this time, processor P will steal tasks and steal some tasks from the local queues of other threads. This is called sharing the pressure of other threads and improving the utilization of its own threads.

The source code is in src\runtime\proc.go\stealWork. If you are interested, you can take a look.

Where should the newly created coroutine be allocated?

Should the newly created coroutine be allocated to the local or global queue? Score:

• Go thinks that the new coroutine has a high priority, so it first looks for the local queue to put it in. Enter and jump in line.
• When the queue of this team is full, it will be put into the global queue.

The actual process is:

1. Randomly search for P
2. Put the new coroutine into P's runnext, which means The coroutine will be run next and the queue will be jumped.
3. If P's coroutine is full, it will be put into the global queue

The source code is in src\runtime\proc.go \newproc function.

// Create a new g running fn.
// Put it on the queue of g's waiting to run.
// The compiler turns a go statement into a call to this.
func newproc(fn *funcval) {
   gp := getg()
   pc := getcallerpc()
   systemstack(func() {
      newg := newproc1(fn, gp, pc) // 創(chuàng)建新協(xié)程

      pp := getg().m.p.ptr()
      runqput(pp, newg, true) // 尋找本地隊(duì)列放入

      if mainStarted {
         wakep()
      }
   })
}

Conclusion

This article initially introduces the GMP scheduling model, and specifically introduces how processor P and thread M obtain coroutines.

Processor P solves the problem of multi-thread mutual exclusion to obtain coroutines and improves the efficiency of scheduling coroutines. However, no matter whether coroutines are in local or global queues, it seems that they are only executed sequentially. So what about Go? How to implement asynchronous and concurrent execution of coroutines? Let’s continue the analysis in the next article (although no one will read it...).

Recommended learning: Golang tutorial

The above is the detailed content of An in-depth analysis of the reasons why there is a GMP scheduling model in the Go language. For more information, please follow other related articles on the PHP Chinese website!