What process resources are shared between threads?

[[357394]]

Processes and threads are two topics that programmers cannot avoid. These two abstract concepts provided by the operating system are really too important. There is an extremely classic question about processes and threads, that is, what is the difference between processes and threads? I believe that many students have a vague understanding of the answer.

Remembering doesn't necessarily mean you understand

Some students may have memorized this question by heart: "Process is the unit of resource allocation of the operating system, thread is the basic unit of scheduling, and threads share process resources." But do you really understand the last sentence above? What process resources are shared between threads? What does shared resources mean? How is the mechanism of shared resources implemented? If you don't have the answer to this, it means that it is almost impossible for you to write a multi-threaded program that works correctly, and it also means that this article is prepared for you.

Thinking in reverse

Charlie Munger often says: "Think the other way around, always think the other way around." If you are unclear about which process resources are shared between threads, you can also think about it the other way around, that is, which resources are private to the threads.

Thread-Private Resources

The essence of thread operation is actually the execution of a function. The execution of a function always has a source, which is the so-called entry function. The CPU starts to execute from the entry function to form an execution flow, but we artificially give the execution flow a name, which is called a thread. Since the essence of thread operation is the execution of a function, what information does the function execution have? In the article "What does the function look like in memory when it is running", we said that the information of the function runtime is saved in the stack frame. The stack frame saves the return value of the function, the parameters for calling other functions, the local variables used by the function, and the register information used by the function. As shown in the figure, suppose function A calls function B:

In addition, the information of the CPU executing instructions is stored in a register called the program counter, through which we know which instruction to execute next. Since the operating system can suspend the thread at any time, we can save and restore the value in the program counter to know where the thread was suspended and where to continue running.

Since the essence of thread running is function running, and the function runtime information is stored in the stack frame, each thread has its own independent and private stack area.

At the same time, when a function is running, additional registers are needed to save some information, such as some local variables. These registers are also thread-private, and one thread cannot access this type of register information of another thread.

From the above discussion, we know that so far, the stack area, program counter, stack pointer and registers used by the function execution of the thread are private to the thread.

The above information has a unified name, which is thread context.

We have also said that the operating system needs to interrupt the running of threads at any time when scheduling threads and needs to be able to continue running after the threads are suspended. The reason why the operating system can achieve this is based on the thread context information.

Now you should know which ones are thread-private.

Apart from that, the rest are shared resources between threads.

So what's left? And these in the picture.

This is actually what the process address space looks like, that is, threads share all the contents of the process address space except the thread context information, which means that threads can directly read these contents. Next, let's look at these areas separately.

Code Area

What is stored in the code area in the process address space? Some students may have guessed it from the name. Yes, it stores the code we wrote, or more accurately, the compiled executable machine instructions.

So where do these machine instructions come from? The answer is that they are loaded into the memory from the executable file. The code area in the executable program is used to initialize the code area in the process address space.

The code area is shared between threads, which means that any function in the program can be put into a thread for execution, and there is no situation where a function can only be executed by a specific thread.

Data Area

The data area in the process address space, where the so-called global variables are stored.

What are global variables? Global variables are variables that you define outside of a function, like this in C:

 char c; // global variable 
 
 void func() { 
     
 }

The character c is a global variable, which is stored in the data area of ​​the process address space.

During the programmer's execution, that is, run time, there is only one instance of the global variable in the data area, and all threads can access the global variable.

It is worth noting that there is a special type of "global variable" in C language, which is a variable modified with the static keyword, like this:

 void func(){
 static   int a = 10;
 }

Note that although variable a is defined inside the function, it still has the characteristics of a global variable, that is, variable a is placed in the data area of ​​the process address space. Even after the function is executed, the variable still exists. Ordinary local variables are recycled together with the function stack frame when the function call ends, but the variable a here will not be recycled because it is placed in the data area.

Such variables are also visible to every thread, which means that every thread can access the variable.

Heap Area

The heap area is familiar to programmers. The data we create with malloc or new in C/C++ is stored in this area. Obviously, as long as the address of the variable, that is, the pointer, is known, any thread can access the data pointed to by the pointer. Therefore, the heap area is also a resource shared by threads and belongs to the process.

Stack Area

Oh, wait! Didn't I just say that the stack area is a thread-private resource? Why are we talking about the stack area again now?

Indeed, from the abstract concept of thread, the stack area is private to the thread. However, from the actual implementation point of view, the rule that the stack area is private to the thread is not strictly followed. What does this sentence mean?

Generally speaking, note that the word used here is usually, generally speaking the stack area is thread private, and since there are usually times, there are unusual times.

It is not common because unlike the strict isolation between process address spaces, the thread stack area is not strictly protected by an isolation mechanism. Therefore, if a thread can get a pointer from another thread's stack frame, then the thread can change the other thread's stack area, which means that these threads can arbitrarily modify variables that belong to another thread's stack area.

This gives programmers great convenience to a certain extent, but at the same time, it can also lead to bugs that are extremely difficult to detect.

Imagine that your program runs well, but suddenly a problem occurs at some point. After locating the problematic line of code, you cannot find the cause at all. Of course, you cannot find the cause of the problem, because there is no problem with your program in the first place. It is someone else's problem that causes your function stack frame data to be corrupted and thus creates a bug. Such problems are usually difficult to find the cause, and you need to be very familiar with the entire project code. Some commonly used debugging tools may not be of much use at this time.

Having said so much, you may ask, how does a thread modify data that belongs to other threads?

Next, let's explain it with a code example.

Modify thread private data

Don't worry, the following code is simple enough:

 void thread(void* var) {
 int * p = ( int *)var;
 *p = 2;
 } 
 
 int main() {
 int a = 1;
 pthread_t tid; 
     
    pthread_create(&tid, NULL , thread, (void*)&a);
 return 0;
 }

What does this code mean?

What does this code mean?

First, we define a local variable in the stack area of ​​the main thread, which is the line of code int a = 1. Now we know that the local variable a belongs to the private data of the main thread, but then we create another thread.

In the newly created thread, we pass the address of variable a to the newly created thread as a parameter, and then I will take a look at the thread function.

In the newly created thread, we get the pointer of variable a and then change it to 2. In this line of code, we modify the private data that originally belonged to the main thread in the newly created thread.

Now you should understand that although the stack area is the private data of the thread, since there is no protection mechanism added to the stack area, the stack area of ​​one thread is visible to other threads, which means that we can modify the stack area belonging to any thread.

As we have said above, this brings great convenience to programmers as well as endless troubles. Imagine the above code. If it is really required by the project, then there is nothing wrong with writing the code in this way. However, if the newly created thread modifies the private data belonging to other threads due to a bug, then it is difficult to locate the problem, because the bug may be far away from the line of code where the problem is exposed, and such problems are usually difficult to troubleshoot.

Dynamic Link Library

In addition to what is discussed above, there is actually other content in the process address space. What else is there?

This starts with the executable program.

What is an executable program? In Windows, it is the familiar exe file, and in the Linux world, it is the ELF file. These programs that can be directly run by the operating system are what we call executable programs.

So how do executable programs come about?

Some students may say, nonsense, isn’t it generated by the compiler?

In fact, this answer is only half correct.

Assuming that our project is relatively simple and has only a few source code files, how does the compiler convert these source code files into a final executable program?

It turns out that after the compiler translates the executable program into machine instructions, there is another important step, which is linking. Only after linking is completed can an executable program be generated.

The linker is responsible for completing the linking process.

The linker can have two linking modes, namely static linking and dynamic linking.

Static linking means that all machine instructions are packed into the executable program at once, and dynamic linking means that we do not pack the dynamic link part into the executable program, but instead look for the dynamic link part of the code in the memory after the executable program is running. This is the so-called static linking and dynamic linking.

An obvious benefit of dynamic linking is that the size of the executable program will be very small, just like when we see an exe file under Windows, it may be very small, then the exe is likely to be generated by dynamic linking.

The library generated by the dynamic link part is the dynamic link library we are familiar with. It ends with DLL in Windows and with so in Linux.

Having said so much, what does this have to do with thread sharing resources?

It turns out that if a program is generated by dynamic linking, then part of its address space contains the dynamic link library, otherwise the program will not run, and this part of the address space is also shared by all threads.

That is to say, all threads in the process can use the code in the dynamic link library. The above is actually a very brief introduction to the topic of linking. For a detailed discussion on the topic of linking, please refer to the "Complete Understanding of Linker" series of articles.

document

Finally, if the program opens some files during running, the open file information is also saved in the process address space, and the files opened by the process can also be used by all threads, which is also a shared resource between threads.

One More Thing: TLS

Is that all for this article? In fact, there is one more item about thread private data that has not been explained in detail, because if I continue to explain it, this article will be too long, and the part that has been explained in this article is sufficient. The remaining point is just a supplement, that is, an optional part. If you are not interested in it, you can skip it, no problem.

There is another technology for thread-private data, which is thread local storage, Thread Local Storage, TLS. What does this mean? In fact, as the name suggests, the so-called thread local storage refers to the variables stored in this area. There are two meanings:

• Variables stored in this area are global variables and can be accessed by all threads.
• Although it seems that all threads access the same variable, the global variable belongs to one thread alone, and modifications made by one thread to this variable are not visible to other threads.

After all this, you still don't understand? Don't worry, if you still don't understand after reading these two pieces of code, come and hit me. Let's look at the first piece of code first. Don't worry, this piece of code is very, very simple:

 int a = 1; // global variable 
 
 void print_a() {
 cout<<a<<endl;
 } 
 
 void run() {
 ++a;
 print_a();
 } 
 
 void main() {
 thread t1(run);
 t1.join (); 
 
 thread t2(run);
 t2.join ();
 }

How about it? This code is simple enough. The above code is written in C++11. Let me explain what this code means.

• First we create a global variable a with an initial value of 1
• Next, we create two threads, each of which adds 1 to the variable a.
• The join function of a thread indicates that the next code will be executed only after the thread has finished running.

So what will be printed when this code is run? The initial value of the global variable a is 1. After the first thread adds 1, a becomes 2, so 2 will be printed; after the second thread adds 1 again, a becomes 3, so 3 will be printed. Let's take a look at the running results:

 2
 3

It seems that our analysis is correct. The global variable finally becomes 3 after the two threads add 1 respectively. Next, we modify the definition of variable a slightly, and keep the other codes unchanged:

 __thread int a = 1; // thread local storage

We see that the global variable a is modified with the keyword __thread, which means that we tell the compiler to put the variable a in thread local storage. What changes will this bring to the program? Simply run it and you will know:

 2
 2

Is it the same as you thought? Some students may be surprised. Why did we add variable a twice, but why did the second run still print 2 instead of 3? Think about why. It turns out that this is the role of thread local storage. The modification of variable a by thread t1 will not affect thread t2. After thread t1 adds variable a to 1, it becomes 2, but for thread t2, variable a is still 1 at this time, so it is still 2 after adding 1. Therefore, thread local storage allows you to use a global variable that belongs exclusively to a thread. In other words, although the variable can be accessed by all threads, the variable has a copy in each thread, and the modification of the variable by one thread will not affect other threads.

Summarize

How about it? I didn't expect that there would be so many knowledge points behind the simple sentence "threads share process resources" in the textbook. The knowledge in the textbook seems easy, but it is not simple. I hope this article can help you understand how much processes and threads can help.

This article is reprinted from the WeChat public account "Coder's Desert Island Survival", which can be followed through the following QR code. To reprint this article, please contact the Coder's Desert Island Survival public account.