Shulou(Shulou.com)06/02 Report--

Today, I will introduce to you how to understand Goroutine. The content of the article is good. Now I would like to share it with you. Friends who feel in need can understand it. I hope it will be helpful to you. Let's read it along with the editor's ideas.

Concurrency in the Go language uses Goroutine,Goroutine as a lightweight thread, or user-level thread. Much like Java's Thread, the usage is simple:

Go fun (params)

Equivalent to Java

New Thread (someRunnable) .start ()

Although similar, Goroutine is very different from Java Thread.

Thread in Java uses an one-to-one model of the thread model, where each user thread corresponds to a kernel-level thread.

The figure above has two CPU and then four Java thread. Each Java thread is actually a kernel-level thread, scheduled by the kernel-level thread scheduler, and takes turns using two CPU. The kernel-level thread scheduler has absolute power, so it is placed below. The kernel-level thread scheduler uses a fair algorithm to have four threads use two CPU.

Go's Goroutine is a user-level thread. The same 4 Goroutine may only correspond to two kernel-level threads. The Goroutine scheduler allocates four Goroutine to two kernel-level threads, and the use of CPU by these two kernel-level threads is allocated by the kernel thread scheduler.

Compared with the kernel-level thread scheduler, Goroutine's scheduler is equal to Goroutine, so it is put on the same level as Goroutine. The scheduler has the same power as the dispatched, so the dispatched can be disobedient. If a Goroutine occupies the CPU, it won't let go, and there's nothing the dispatcher can do with it.

It is also the following code:

Void run () {int a = 1; while (1) {a = 1;}}

In Java, if there are multiple such threads, they can use CPU equally. But in Go, if there are more than one such Goroutine, in the case of a certain number of kernel-level threads started (usually equal to the number of CPU), then the first Goroutine will always occupy the CPU, and the other Goroutine will starve and starve to death, because it can not actively give up CPU and do not cooperate with others. When it comes to cooperation, we need to talk about coroutine, which can be regarded as cooperative routine. It needs to cooperate and assist each other in order to work normally, so it is called Cooperative process.

The collaborative process does not need a scheduler, it works entirely by coordinating with each other. The definition of cooperative program is very abstract in academic. at present, in practical application, cooperative program usually uses a single kernel-level thread to change the difficult callback method used in asynchronous programming to look like synchronous programming.

For example, nodejs is asynchronous single-threaded event-driven, if there are multiple asynchronous operations in a piece of code, such as calling a payment system first, getting the results and then updating the database, then you may need to use callback nested. The pay function is an operation that calls the payment system, sends a request asynchronously and returns, and then triggers the first callback function after the payment event is completed. This function updates the database and is another asynchronous operation. After the asynchronous operation is completed, the callback function that returns the update result is triggered again. There are only two asynchronous operations here, and if there are many, there may be a lot of nesting.

Pay (amount, callback (payamount) {update (payamount, callback (result) {return result;})})

Using a cooperative program, it can look like a synchronous operation.

Pay (amount) {/ / Asynchronous, immediately return / / payamount can only be assigned payamount = dopay (amount) after the operation is completed; after the yeild main;// returns control to the master routine / / dopay event, the master routine will call up the routine and / / continue to execute doupdate result=doupdate (payamount); yeild main;// returns control to the master routine return result;} again

(all the above are pseudo codes)

Change the original nested callback into a co-program, and the logic will be much clearer.

Unlike Coroutine, Goroutine developers do not need to care about how the Goroutine is called up or give up control, but leave it to the Goroutine scheduler to manage. Developers don't have to worry about it, but the Go compiler will do the job for you, because Goroutine must actively hand over control in order to be managed by the scheduler. First of all, we can think that it is meaningless to write the Goroutine which is an endless loop and does not call any other functions. If we do write such code in practical application, then the developer is not a qualified programmer. A Goroutine will always call other functions, one is a function written by the developer, and the other is API provided by the Go language. Then the compiler and these API can do something about it.

such as

Void run () {int a = 0; int b = 1; a = b * 2; for (int I = 0; I < 100; iTunes +) {a = func1 (a);}}

Then the compiler may secretly add a few statements where other functions are called, such as:

Void run () {int a = 0; int b = 1; a = b * 2; for (int I = 0; I < 100; iTunes +) {/ / enter the scheduler, or enter the scheduler schedule () with a certain probability; a = func1 (a);}}

And for example,

Void run () {socket = new socket (); while (buffer = socker.read ()) {deal (buffer);}}

Socker.read () is a system function provided by the Go language, so the Go language may add some operations to it. After reading the data, it goes to the scheduler and lets the scheduler decide whether the Goroutine continues to run.

The following Go language code, set the kernel-level threads to 2, then the main thread will starve to death, and add a sleep to the func1, so that the func1 has a chance to give up control.

Of course, the scheduler of the Go language is much more complicated than this. Goroutine is still different from the protocol, and the implementation principle is the same, but the purpose of Goroutine is to achieve concurrency. In the GE language, developers cannot create kernel-level threads, but can only create Goroutine. The purpose of the protocol, as shown above, is the above. Go language is suitable for writing applications with high concurrency, because the cost of creating a Goroutine is very low, and the context switching overhead of Goroutine is also very low. Compared with creating kernel-level threads, the cost of Goroutine may be only one-tenth or even one percent, and it does not take up kernel space. Each kernel-level thread takes up a large amount of kernel space, and the maximum number of threads that can be created is only a few thousand, while Goroutine can easily create tens of thousands of threads.

The underlying implementation of Goroutine is implemented with makecontext,swapcontext,getcontext,setcontext functions on Linux. These system calls can save and switch the thread context in user space.

These are all the contents of how Goroutine understands. For more content related to how Goroutine understands, you can search the previous articles or browse the following articles to learn! I believe the editor will add more knowledge to you. I hope you can support it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.