preface

This is a pre-post to write about concurrency in Go, but it will be a lot of content, so I will write it in a separate blog. (Actually for the big teapot)

We know that coroutines are used in Go, which is different from what we’ve seen before, whether it’s single-threaded in JavaScript (parent and child processes) or multi-threaded in Java. Here I’m going to talk about some of the ideas between the three.

Processes and Threads

In fact, when we operate the computer every day, there is a process here, for example, I now open Google Chrome, and then go to nuggets website and in the process of writing this article, in fact, inside the computer, I’m starting a Google Chrome process, and while I’m typing here, Computer pinyin I typed out a letter to identify the process of a man, this is through the thread to complete.

We know that a CPU can only execute one process task at a time, that is, when a process starts being executed by the CPU. Other processes are suspended, normally until the CPU has finished executing this process before it can execute other processes. However, there is a scheduler inside the computer system, which is used to schedule the execution of each process under the CPU.

For example, there are two processes AB, A executes for 0.3 seconds, then the scheduler will let B execute, and the execution of A will be saved, and then B executes for A period of time, or after the execution is finished, then cut back to continue the execution of A process.

Note that:

A process is the basic unit of resource allocation

Threads are the basic unit of CPU scheduling allocation

That is, a process acts on the entire computer system, but a thread only acts on the CPU that executes the process. Therefore, a CPU can only execute one process, but a process can have many threads. At the same time, processes are isolated from each other, but threads do communicate with each other.

This may be a bit abstract, with a more practical example – league of Legends.

In masturbation, a game room, like a CPU, can have anywhere from 1 to 10 players, who can only play against each other in the game (messages between threads) and not interact with players in other rooms (isolation between processes).

As a result of these features, the concept of multithreading and multi-process models is derived, but since processes and threads are not the focus of this article, I won’t mention them here.

Coroutines in Go

Coroutines are very similar to threads, but with a slight difference. Here are some of the more obvious features of coroutines:

  1. Multithreading is executed by alternating between threads, so is coroutine. The difference is that thread switching is performed by the operating system, while coroutine switching is scheduled by the user himself, such as the task scheduler in Go. In this way, the overhead caused by context switching is reduced.

  2. The memory required to create a coroutine is much smaller. Generally, a thread needs about 1 MB of memory, but a coroutine is about 2K, so the space required to create a thread can provide more coroutines.

  3. Since only one thread is executing when the coroutine is executing, this avoids the problem of multiple threads reading and writing while executing, which is also known as the locking mechanism. In the thread, it only needs to switch by judging the state. (e.g. Chan in Go)

  4. Suitable for scenarios with high concurrency, but not for scenarios requiring high density computing.

It is also very easy to create a coroutine in Go

	go func(a){... What to do}()Copy the code

You only need to go through a simple, very convenient.

Here is a diagram of the difference between coroutines and threads found on the Web.

The last

Since this is a pre-article, I won’t Go too far into the use of the Go language for example concurrency and channels (which is actually lazy), so have a good weekend