Research on synchronization mutex mechanism in Linux

In the operating system, access to shared resources requires a synchronous mutex mechanism to ensure the correctness of its logic. First, let's talk about atomic operations:

| 1. Atomic Operations (Atomic Operations ):

In terms of definition, atomic operations should be similar to atomic operations that cannot be further divided. However, in fact, they are slightly different. The more accurate definition should be:One or more operations that cannot be interrupted.

In a single processor system, operations that can be completed in a single command can be considered as "Atomic operations", because the interruption only occurs at the command edge. The multi-processor structure is different. Because multiple processors run independently in the system, operations that can be completed in a single command may be affected. On the X86 platform, the CPU provides a means to lock the bus during command execution. There is a lead on the CPU # HLOCK pin connected to the North Bridge Chip. If the prefix "LOCK" is added before the assembly program instructions ", the compiled machine code lowers the potential of the # HLOCK pin when the CPU executes this command until the execution of this command ends, thereby locking the bus, in this way, other CPUs on the same bus cannot access the memory temporarily through the bus, ensuring the atomicity of memory access for this command in a multi-processor environment.

| 1.1 why atomic operations are required

Let's take an example. Suppose we use two threads to increase the number of global variable indexes to 10. We write the thread function as follows:

　　

The execution results are as follows. We can see that the execution is performed twice, but the results are different (not the expected value is 10). In fact, the results of each execution may be different. Theoretically, the two threads execute the auto-increment operation five times at the same time. If the execution is correct, the result of 10 is always returned. However, although the two threads can be executed simultaneously, the index value does not increase from 1 to 10. In the figure, when the mthread program is executed for the first time, after thread 1 increases the index to 5, thread 2 returns the result of 2. What is the problem?

　　

 

We know that in a computer, the value of a variable is stored in the memory. To know the value of a variable stored in the memory, we need to read the memory, to update the value of this variable, you must write it back. If the entire operation cannot be interrupted, the above results will not appear, so there must be something in the middle. In fact, I ++ is indeed not Atomic. After the program is compiled into assembly code, we can see that I ++ is actually modified by Read-Modify) -Write:

　　

　　

As shown in, the two threads run on the two processor cores respectively. Assuming that the I value is 0 at the beginning, thread 1 first reads the I value and puts it in the ax register, at this time, thread 2 also reads the value of I, then add eax, 1, and then write back to the address of I, at this time, the value of I is 1; then thread 1 executes add eax, 1, write back to the address of I, so the value of I is 1, not 2. If I ++ needs to be changed to an atom, some additional methods are required.

| 1.2 Implementation of sub-operations in Linux

With the sensory knowledge above, it is now logical to implement it. The implementation of atomic operations in Linux is mainly in Atomic_32.h under the linux-2.6.28 \ arch \ x86 \ include \ asm directory, including a series of inline functions (because the code of these functions is not long, (embedded assembly code is basically used ). First, let's look at the definition of the atomic Data Structure atomic_t:

1 /*2  * Make sure gcc doesn't try to be clever and move things around3  * on us. We need to use _exactly_ the address the user gave us,4  * not some alias that contains the same information.5  */6 typedef struct {7     int counter;8 } atomic_t;

Next let's look at how to implement atomic operations:

 1 /** 2  * atomic_add - add integer to atomic variable 3  * @i: integer value to add 4  * @v: pointer of type atomic_t 5  * 6  * Atomically adds @i to @v. 7  */ 8 static inline void atomic_add(int i, atomic_t *v) 9 {10     asm volatile(LOCK_PREFIX "addl %1,%0"11              : "+m" (v->counter)12              : "ir" (i));13 }

The code above is truncated from Atomic_32.h, that is, the atomic addition operation. The implementation of this function adopts the embedded assembly method. First, declare the LOCK prefix (actually a macro definition) and execute the command addl % 1, % 0 in an atomic way, number of input and output operations. The plus signs in "+ m" indicate that the output is readable and writable, and the brackets indicate the atomic variable v-> counter. m indicates that the output is stored in the memory. In "ir", I indicates that the input is a direct operand, and r indicates that the input I is stored in the register.

The addition of atoms makes it difficult to subtract atoms:

 1 /** 2  * atomic_sub - subtract integer from atomic variable 3  * @i: integer value to subtract 4  * @v: pointer of type atomic_t 5  * 6  * Atomically subtracts @i from @v. 7  */ 8 static inline void atomic_sub(int i, atomic_t *v) 9 {10     asm volatile(LOCK_PREFIX "subl %1,%0"11              : "+m" (v->counter)12              : "ir" (i));13 }

Other atomic operations will not be used as an example. In short, the principle is that, in competitive access, the logic of the last operation must be ensured, you must set some operations or commands as atomic. Atomic operations are the basis of some other synchronization mutex mechanisms. With Atomic operations, you can implement other synchronization mutex mechanisms in multi-core systems.

 

 

References:

Http://edsionte.com/techblog/archives/1809.

Http://blog.csdn.net/qb_2008/article/details/6840808.