Linux的原子操作和同步机制.docVIP

Linux的原子操作与同步机制 ? 并发问题 现代操作系统支持多任务的并发，并发在提高计算资源利用率的同时也带来了资源竞争的问题。例如C语言语句“count++;”在未经编译器优化时生成的汇编代码为。 当操作系统内存在多个进程同时执行这段代码时，就可能带来并发问题。 假设count变量初始值为0。进程1执行完“mov eax, [count]”后，寄存器eax内保存了count的值0。此时，进程2被调度执行，抢占了进程1的CPU的控制权。进程2执行“count++;”的汇编代码，将累加后的count值1写回到内存。然后，进程1再次被调度执行，CPU控制权回到进程1。进程1接着执行，计算count的累加值仍为1，写回到内存。虽然进程1和进程2执行了两次“count++;”操作，但是count实际的内存值为1，而不是2！ 单处理器原子操作 解决这个问题的方法是，将“count++;”语句翻译为单指令操作。 Intel x86指令集支持内存操作数的inc操作，这样“count++;”操作可以在一条指令内完成。因为进程的上下文切换是在总是在一条指令执行完成后，所以不会出现上述的并发问题。对于单处理器来说，一条处理器指令就是一个原子操作。 多处理器原子操作 但是在多处理器的环境下，例如SMP架构，这个结论不再成立。我们知道“inc [count]”指令的执行过程分为三步： 1）从内存将count的数据读取到cpu。 2）累加读取的值。 3）将修改的值写回count内存。 这又回到前面并发问题类似的情况，只不过此时并发的主题不再是进程，而是处理器。 Intel x86指令集提供了指令前缀lock用于锁定前端串行总线（FSB），保证了指令执行时不会受到其他处理器的干扰。 使用lock指令前缀后，处理器间对count内存的并发访问（读/写）被禁止，从而保证了指令的原子性。 x86原子操作实现 Linux的源码中x86体系结构原子操作的定义文件为。 linux2.6/include/asm-i386/atomic.h 文件内定义了原子类型atomic_t，其仅有一个字段counter，用于保存32位的数据。 typedef struct { volatile int counter; } atomic_t; 其中原子操作函数atomic_inc完成自加原子操作。 /** ?* atomic_inc - increment atomic variable ?* @v: pointer of type atomic_t ?* ?* Atomically increments @v by 1. ?*/ static __inline__ void atomic_inc(atomic_t *v) { ??? __asm__ __volatile__( ?????? LOCK incl %0 ?????? :=m (v-counter) ?????? :m (v-counter)); } 其中LOCK宏的定义为。 #ifdef CONFIG_SMP ??? #define LOCK lock ; #else ??? #define LOCK #endif 可见，在对称多处理器架构的情况下，LOCK被解释为指令前缀lock。而对于单处理器架构，LOCK不包含任何内容。 arm原子操作实现 在arm的指令集中，不存在指令前缀lock，那如何完成原子操作呢？ Linux的源码中arm体系结构原子操作的定义文件为。 linux2.6/include/asm-arm/atomic.h 其中自加原子操作由函数atomic_add_return实现。 static inline int atomic_add_return(int i, atomic_t *v) { ??? unsigned long tmp; ??? int result; ??? __asm__ __volatile__(@ atomic_add_return\n ?????? 1:???? ldrex?? %0, [%2]\n ?????? ?????? add???? %0, %0, %3\n ?????? ?????? strex?? %1, %0, [%2]\n ?????? ?????? teq???? %1, #0\n ?????? ?????? bne???? 1b ?????? : =r (result), =r (tmp) ?????? : r (v-counter), Ir (i) ?????? : cc); ??? return result; } 上述嵌入式汇编的实际形式为。 1: ldrex? [result], [v-counter] add??? [result]