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

This article mainly explains "how programmers should understand collaborative programs in high concurrency". Friends who are interested might as well take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how programmers should understand the cooperative process in high concurrency".

Needless to say, today's topic is how to thoroughly understand the cooperative process as a programmer.

Ordinary function

Let's first look at a common function, which is very simple:

Def func (): print ("a") print ("b") print ("c")

This is a simple ordinary function. What happens when we call this function?

Call func

Func starts execution until return

Func execution is complete, returning function A

Isn't it simple that the function func executes until it returns and prints out:

A b c

So easy, is there any?

Fine!

Note that this code is written in python, but this discussion of protocols applies to any language, because they are not a feature of a language. We just happen to use python as an example because it's simple enough.

So what is Xiecheng?

From ordinary function to Cooperative Program

Next, we are going to transition from ordinary functions to co-programs.

Unlike ordinary functions, which have only one return point, a co-program can have multiple return points.

What does this mean?

Void func () {print ("a") pause and return print ("b") pause and return print ("c")}

Under an ordinary function, the function will not return until the sentence print ("c") is executed, but under the cooperative program, when the print ("a") is executed, the func will return to the calling function because of the "pause and return" code.

Some students may look confused. Is there anything magical about this? I can also return when I write a return, like this:

Void func () {print ("a") return print ("b") pauses and returns print ("c")}

It is true that it is possible to write a return statement directly, but then the code behind the return will not be executed.

The reason why the co-program is amazing is that we can continue to call the protocol after we return from the program, and continue to execute from the last return point of the program.

This is amazing enough, just like when Sun WuKong says "yes", the function is paused:

Void func () {print ("a") definite print ("b") definite print ("c")}

At this point, we can return to the calling function, and when the calling function remembers the protocol, we can call it again, which will continue to execute from the last return point.

Amazing, do not, concentrate, do not turn over.

It's just that the phrase "fixed" used by Sun Dasheng is generally called yield in programming languages (there may be different implementations in other languages, but the essence is the same).

It should be noted that when an ordinary function returns, any information about the runtime of the function will no longer be stored in the address space of the process, but after the co-program returns, the runtime information of the function needs to be saved. so what exactly is the runtime state of the function like in memory? you can refer to this question.

Next, let's take a look at the collaboration process with the actual code.

Show Me The Code

Below we use a real example to explain, the language uses python, unfamiliar students do not have to worry, there will be no threshold for understanding.

In python, the word "determined" also uses the keyword yield, so our func function becomes:

Void func () {print ("a") yield print ("b") yield print ("c")}

Notice that our func is no longer a simple function, but is upgraded to a co-program, so how do we use it? it's simple:

Def A (): co = func () # get the protocol next (co) # call the protocol print ("in function A") # do something next (co) # call the protocol again

We see that although the func function does not have a return statement, that is, although it does not return any value, we can still write code such as co = func (), which means that co is the co-program we got.

Next, we call the protocol, use next (co), and run function A to see what the result is when we get to line 3:

A

Obviously, as expected, the co-program func pauses and returns function An after print ("a") because it executes yield.

And then there's line 4, and there's no doubt that the A function is doing something of its own, so it prints:

An in function A

Next is the key line. What should be printed when line 5 invokes the protocol again?

If func is a normal function, the first line of code in func is executed, that is, printing a.

But func is not an ordinary function, but a co-program, which, as we said before, will continue to run at the last return point, so what should be executed here is the code after the first yield of the func function, that is, print ("b").

An in function A b

You see, the co-program is a magical function that remembers the previous execution state by itself and continues from the last return point when called again.

Graphical interpretation

To give you a more thorough understanding of the protocol, let's look at it again graphically, starting with ordinary function calls:

In this figure, the instruction sequence of the function is represented in the box. If the function does not call any other function, it should be executed from top to bottom, but other functions can be called in the function, so its execution is not simple from top to bottom. The arrow line represents the direction of the execution flow.

We can see from the figure that we first came to the funcA function, and after a period of execution, we found that another function, funcB, was called. At this time, the control was transferred to this function, and after the execution was completed, we went back to the call point of the main function to continue execution.

This is a normal function call.

The next step is to assist the journey.

Here, we still execute the program in the funcA function first. After running for a period of time, we call the program, and the program starts to execute until the first starting point, and then returns the funcA function like an ordinary function. The funcA function calls the program again after executing some code. Note that the program is different from the ordinary function at this time. The program is executed not from the first instruction, but from the last starting point. When the second starting point is encountered after a period of execution, the co-program returns the funcA function again like an ordinary function, and the whole program ends after the funcA function is executed for a period of time.

Function is just a special case of co-program.

How, magical is not magical, unlike ordinary functions, the co-program can know where it was last executed.

Now you should understand that the co-program saves the running state of the function when the function is suspended, and can recover from the saved state and continue to run.

Is there a familiar smell? isn't this the scheduling of threads by the operating system? threads can also be paused. The operating system saves the running state of threads and then schedules other threads. After that, the thread can continue to run when it is assigned CPU again, as if it had not been paused.

It's just that thread scheduling is implemented by the operating system, which is invisible to programmers, while co-programs are implemented in user mode and visible to programmers.

This is why some people say that co-programming can be understood as a user-mode thread.

There should be applause here.

In other words, the programmer can now play the role of an operating system, and you can control when the program runs and when it is paused, which means that the scheduling of the program is in your own hands.

In the matter of cooperation, it is up to you to dispatch.

When you write yield in the protocol, you want to pause it, and when you use next (), you want to run it again.

Now you can understand why a function is just a special case of a co-program. A function is actually a co-program without a starting point.

The history of the cooperation process

Some students may think that cooperative programming is a relatively new technology, but in fact, the concept of cooperative programming has been put forward as early as 1958, you know, the concept of thread has not been put forward yet.

By 1972, this concept was finally implemented in programming languages: Simula 67 and Scheme.

However, the concept of Xiecheng never became popular, and even in 1993, some people wrote archeological papers to dig out the ancient technology of Xiecheng.

Because there are no threads in this period, if you want to write concurrent programs in the operating system, you will have to use techniques such as collaborative programs, and then threads begin to appear, and the operating system finally begins to support the concurrent execution of programs. In this way, the cooperative program gradually faded out of the programmer's sight.

Until recent years, with the development of the Internet, especially the arrival of the mobile Internet era, the server's demand for high concurrency is getting higher and higher. Collaborative process has once again returned to the mainstream of technology, and all major programming languages have supported or planned to support collaborative programming.

So how on earth is the cooperation process realized?

How is the collaborative process realized?

Let's think about it from the nature of the problem.

What is the nature of the cooperative process?

It is actually a function that can be paused and resumed.

So what does it mean that it can be paused and resumed?

Students who have watched the basketball game must know (those who have not seen it can also know) that the basketball game can also be suspended at any time. When the game is paused, people need to remember which side the ball is and where they stand. When the game continues, everyone returns to their positions, and the referee whistles the game as if the game has not been suspended.

Do you see the crux of the problem? the reason why the game can be suspended or continued is that the state of the game is recorded (position, which side of the ball), which is often referred to as the context in computer science, context.

Back to Xiecheng.

The reason why the collaboration program can be paused or can continue, then be sure to record the state when it is paused, that is, the context, and restore its context (state) when it continues to run, then the next natural question is, what is the state of the function runtime?

The answer to this key question lies in the article "what does a function look like in memory after it is run?" all the state information of the function runtime is on the function runtime stack.

The function runtime stack is the state we need to save, the so-called context, as shown in the figure:

From the figure, we can see that there is only one thread in the process, and there are four stack frames in the stack area. Main function calls A function, A function calls B function, and B function calls C function. When C function is running, the state of the whole process is shown in the figure.

Now that we know that the runtime state of the function is saved in the stack frame in the stack area, here comes the point.

Since the runtime state of the function is saved in the stack frame in the stack area, if we want to pause the run of the protocol, we must save the data of the entire stack frame, so where should we save the data in the entire stack frame?

Think about this: which part of the memory area of the entire process is dedicated to storing data for a long time (process life cycle)? Is your mind going blank again?

Don't go blank yet!

Obviously, this is the heap area, heap. We can save the stack frames in the heap area, so how do we save the data in the heap area? I hope you are not dizzy, opening up space in the heap area is malloc in our commonly used C language or new in C++.

What we need to do is to apply for a section of space in the heap area to save the entire stack area of the cooperative program, and then copy out of the heap area to restore the function runtime state when we need to restore the running of the cooperative program.

Think about it again, why do we bother going back and forth with copy data?

In fact, what we need to do is to directly open up the stack frame space needed for the operation of the protocol in the heap area, so that there is no need to copy data back and forth, as shown in the figure.

From the figure, we can see that two programs are opened in the program, and the stack areas of both programs are allocated on the heap, so that we can interrupt or resume the execution of the program at any time.

Some students may ask, what is the role of the stack at the top of the process address space now?

This area is still used to hold function stack frames, except that these functions are not run in a co-program but in a normal thread.

As you should see by now, there are actually three execution flows in the above figure:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

An ordinary thread

Two processes of cooperation

Although there are three execution flows, how many threads have we created?

A thread.

Now you can see why you want to use co-programs. Theoretically, we can open numerous concurrent execution flows using co-programs, as long as there is enough heap space and there is no overhead to create threads, all scheduling and switching of co-programs take place in user mode, which is why co-programs are also called user-mode threads.

Where's the applause?

So even if you create an N-multiple co-program, there is still only one thread in the eyes of the operating system, which means that the co-program is invisible to the operating system.

This may be the reason why the concept of co-programming was put forward earlier than thread. it may be that programmers who write ordinary applications first encounter the need for multiple parallel flows than programmers who write operating systems. At that time, there may be no concept of the operating system, or the operating system does not have the need for parallelism, so non-operating system programmers can only implement the execution flow, that is, the collaboration program.

Now you should have a clear understanding of Xiecheng.

At this point, I believe you have a deeper understanding of "how programmers should understand the collaborative process in high concurrency". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.