For a Linux beginner, it was quite difficult to read this book. I started reading Volume 1 at the same time as I was reading Volume 2. So my understanding of the articles or some points may not be very accurate or even have problems. You are welcome to point them out. I am also very happy to participate in this trial of the book. In fact, it may be better for me to have a force to motivate me to finish reading this book and avoid finding reasons to delay it. Thanks to the forum and the author.
Now let me start with some of my feelings about reading the first chapter. When I first looked at the table of contents, I felt that this chapter should be expected to be finished quickly. After all, who doesn’t frequently use concurrency and synchronization? But just like how can you be considered a good cook if you can’t even make a bowl of fried rice? The structure of the chapter is the same as the style of Volume 1. It starts with high-frequency interview questions and provides various questions for designing this chapter. I roughly read these questions, then read the subsequent sections, and found the answer to a question. Then, in the process of continuing to find the next question, it can still stimulate my reading pleasure. After reading the entire chapter, I look back at these questions. If you have mastered all of them, you can be considered to have entered this knowledge point. However, if you don’t combine it with actual use, you will always feel like you are just talking about it on paper. But the purpose of reading this book is to be able to consider this aspect when you encounter related problems in the future, and I feel it is worth it.
Chapter 1- Concurrency and synchronization, from atomic operations -> spin locks -> semaphores -> RCU, there are familiar atomic operations, semaphores, mutex locks, and relatively unfamiliar operations. Looking at the description in a small section, you can feel the limitations and optimizations of concurrency and synchronization. Some may seem to be the same in function, but in some scenarios it is recommended to use one of them because it can be faster and save more resources. Of course, it also has its own limitations. For example, atomic operations have low overhead, but they are used for data variables in critical sections.
bits and other simple data structures. For example, spin locks have specific developments, such as MCS locks, queued spin locks, etc. Semaphores and mutexes were actually used quite often in the past. During the use process, I always felt that the two had certain similarities, but I only knew that semaphores should be used in this scenario and mutexes should be used in that scenario. This is the inertial use method. The book says, "Since mutexes are similar to semaphores with a count value equal to 1, why does the kernel community redevelop mutexes instead of reusing the semaphore mechanism?" This is because mutexes are simpler and lighter than semaphores. In the test scenario where lock contention is fierce, mutexes execute faster and have better scalability than semaphores. Of course, the optimization scheme of mutexes has also been transplanted to read-write semaphores. Among them, the optimistic spin-wait mechanism is implemented in the mutex. As the name suggests, when it is found that the lock holder is executing in the critical section and there are no other high-priority processes to be scheduled, the current process firmly believes that the lock holder will soon leave the critical section and release the lock. Therefore, instead of sleeping and waiting, it is better to spin and wait optimistically to reduce the overhead of sleep wake-up. I searched it for a while, and found that optimistic lock and pessimistic lock are just as their names suggest. Optimistic lock thinks that everything is good, and pessimistic lock thinks that everything is bad, so one will block modification and lock acquisition, and the other believes that you will not modify. The following chart in the book gives a more intuitive understanding of the state of the mutex lock at each stage, which can be reflected in the critical section, sleep, optimistic spin wait and other states.
The read-write lock mentioned later solves the problem that the semaphore does not distinguish the read and write attributes of the critical section. By distinguishing the read and write attributes, the read attribute will not be modified, so multiple read attribute threads are allowed to enter concurrently, while the write attribute can only be entered by a single thread, and the read and write processes cannot enter at the same time. In fact, from the perspective of the entire chapter, it is a kind of shallow to deep, or more accurately, from raw materials to semi-finished products and then to various finished products. Atomic operations and memory barriers are like raw materials, spin locks are like semi-finished products, and subsequent semaphore mutex locks and read-write locks are like various finished products. The RCU in the last section is more like a special product that makes full use of everything. The principle of the RCU mechanism can be summarized as RCU records all users of pointers to shared data. When modifying shared data, first create a copy and modify it in the copy. After all reader threads leave the reader critical section, the pointer points to the modified copy and deletes the old data. In short, everyone updates the data after reading. For the read and write process, the read process has no or only a small synchronization overhead, so the atomic operation and memory barrier are abandoned, and the synchronization work is handed over to the write thread. The following are the usage scenarios and features of the lock mechanism in the book. You are also welcome to add to it.
| Lock mechanism |
Features |
Rules of Use |
| Atom manipulation |
Use the processor's atomic instructions, which has
low overhead |
The data in the critical section are simple data
structures |
| Memory Barriers |
Use processor memory barrier instructions or GCC
's barrier instructions |
Adjustment of read and write instruction timing |
| Spin lock |
Spin Wait |
Interrupt context, short-term lock holding, no recursion,
no sleep in critical section |
| signal |
Sleepable lock |
Long-term lock holding |
| Read and write semaphores |
Sleepable locks. Multiple readers can hold the lock
at the same time . There can only be
one writer at a time. Readers and writers cannot
exist at the same time. |
The read/write attribute is useful only after the programmer defines the critical section |
| Mutex |
A mutex lock that can sleep
is faster , and implements a spin-wait mechanism |
Only one thread can hold a mutex at a time, and
the lock holder is responsible for unlocking it, that is,
unlocking it The lock cannot be held recursively, which is not suitable for
complex synchronization scenarios between the kernel and user space. |
| RCU |
There is no overhead for readers to hold locks, multiple
readers and writers can coexist at the same time, and writers
must wait for all readers to leave the critical section
before destroying related data |
Protected resources must be accessed through pointers, such as linked lists, etc. |
In the process of reading this chapter, I actually finished reading it for the first time on the second day, but every time I read it over and over again, I gain new things and learn new things. I may still look back at this part from time to time in the future. At the same time, it is recommended that you can also use some tools like chatgpt when reading, so that you can understand it faster and search for some related nouns and terms. At the same time, if possible, you should still read the author’s Volume 1 first. Some nouns or knowledge in the chapter are explained in Volume 1. This may be more step-by-step and natural. Regarding the semaphores, read-write locks, and RCU mentioned above, there are more detailed descriptions and explanations in the book, which can be more convenient to understand with the help of flowcharts and some case diagrams. Because I am also a beginner, I will not elaborate on this to prevent misunderstandings. Students who are interested can read the original text. I hope I can keep updating new chapters every week,
Finally, take a look at the questions at the beginning of each chapter and see how many you can answer. Maybe you need to read this book, too.
1. In an ARM64 processor, how do you achieve exclusive access to memory?
2. Please give an example of a scenario where the kernel uses memory barriers?
3. Why can’t the critical section of the spin lock sleep (not considering the case of RT-Linux)?
4. What are the shortcomings of the classic spin lock implementation in the Linux kernel? Why does the spin lock critical section not allow preemption?
5. Please explain the characteristics and usage rules of atomic operations, spin locks, semaphores, mutex locks, and RCU. When scanning a VMA in KSM to find valid anonymous pages, if this VMA happens to be destroyed by other CPUs, will there be any problems?
6. In the page_get_anon_vma() function in the mm/rmap.c file, why is the rcu_read_lock() function used? When is the RCU callback function registered? In the select_bad_process() function in mm/oom_kill.c, why is the
rcu_read_lock() function used? When is the RCU callback function registered?
提升卡
变色卡
千斤顶
京公网安备 11010802033920号
