How the Goroutine works

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

In the 36th issue of Golangweekly Go newsletter I found a short essay "How To Goroutines work", and the author, after referring to a lot of information, briefly summarized how Goroutine works, The feeling is perfect for just getting started with gophers (in-depth understanding of goroutine scheduling, you can refer to Daniel Morsing's "the Go Scheduler"). Here is the rough translation below.

First, go language introduction

If you are new to the go language, or if you have no bright to the phrase "concurrency (Concurrency) is not parallel (parallelism)", then take a look at the lecture of Rob Pike on this topic for a total of 30 minutes, I'm sure it's worth your while to spend 30 minutes on this speech.

Summarize the differences between the two (Concurrency and Parallelism): "When people hear the word concurrency (Concurrency), they always think of parallelism (Parallelism), they have a correlation, but they are two distinctly different concepts." In the programming world, Concurrency (Concurrency) is a combination of independent execution processes (process), while parallel (Parallelism) is computed (and possibly associated) concurrently. Concurrency (Concurrency) is about dealing with many things at once (deal with lots of things), while parallel (Parallelism) is doing many things at the same time (do lots of things) ". (Rob Pike "Concurrency is not parallelism")

The go language allows us to write concurrent (Concurrent) programs. It provides goroutine and, more importantly, the ability to communicate between goroutines. Here we will focus on the former (refers to concurrency).

second, goroutines and thread s

Goroutine is a simple model: it is a function that executes concurrently with other goroutines and shares the same address space. The usual usage of goroutines is to create as many groutines as you need, hundreds or even tens of thousands. This usage can be a bit odd for programmers who are used to using C + + or java. Creating so many Goroutines is bound to pay dearly? An operating system thread uses a fixed-size memory as its execution stack, and when the number of threads increases, the cost of switching between threads is quite high. This is also the reason why a service program scenario that creates a new thread for each request is processed.

But Goroutine is completely different. They are initialized and dispatched by the Go runtime, and the operating system simply does not see the presence of Goroutine. All Goroutines are alive and run in multiplexed form on the few threads that the operating system allocates to the application. Creating a goroutine does not require much memory and requires only 8K of stack space (this size has changed in Go 1.3). They allocate and free memory on the heap as needed to achieve their own growth.

The Go Runtime is responsible for dispatching goroutines. Goroutines scheduling is collaborative, and threads are not. This means that every time a thread switches, you need to save/restore all registers, including 16 universal registers, PC (program counter), SP (stack pointer), segment register (segment register), 16 XMM registers, FP coprocessor status, X AVX registers and all MSR. When another goroutine is dispatched, only three registers are saved/restored, namely PC, SP, and DX. The Go scheduler and any modern operating system scheduler are O (1) complex, which means that increasing the number of thread/goroutines does not increase the switching time, but the cost of changing registers is not negligible.

Because Goroutines scheduling is collaborative, a continuous loop of goroutine causes other goroutines running on the same thread to "starve". In Go 1.2, this problem can be more or less mitigated by invoking the go scheduler before or after entering the function, so a loop containing non-inline function calls can be preempted by the scheduler.

Third, goroutine obstruction

As long as the blocking exists, it is undesirable in the OS thread because you have a very small number of threads. If you find that a lot of threads are blocking the network operation or the sleep operation, that is the problem and needs to be fixed. As mentioned earlier, Goroutine is cheap. More crucially, if they block on a network input operation, a sleep operation, a channel operation, or a primitive operation on a sync packet, it does not cause the thread that hosts its multiplexing to block. If a goroutine is blocked on one of these operations, the Go runtime dispatches another goroutine. Even if thousands of goroutine are created, they will not waste system resources if they block on one of the above operations. From the operating system perspective, your program behaves as if it were an event-driven C program.

Iv. the final idea

That's it, Goroutines can run concurrently. However, as with other languages, it is important to organize two or more goroutine to access shared resources at the same time. It is best to use channel to transfer data between different goroutine.

Finally, although you cannot directly control the number of threads created by the Go runtime, you can call runtime. The Gomaxprocs (n) method sets the variable Gomaxprocs to set the number of processor cores used. Increasing the number of processor cores used does not necessarily improve the performance of your program, depending on the design of the program. The Program profiling Diagnostic tool (profiling Tools) can be used to check the actual condition of your program's use of processor cores.

, Bigwhite. All rights reserved.