一直以来对锁比较感兴趣。因为在多核编程中，锁是一个可恨有可爱的东西。说它可恨，是因为锁的使用，降低了并发性，也就降低了性能。可爱之处呢，因为锁的使用有时是无法避免的。那么如何实现一个高性能的锁又是一个很有意思的问题。以后有机会，再跟大家交流一下锁的实现部分。
今天是我在看spinlock的时候，突然想到的问题。这个问题不局限于spinlock，下面的示例我使用mutex来代替。
#include
#include
#include
extern int counter;
extern pthread_mutex_t counter_mutex;
void add_counter(void)
{
pthread_mutex_lock(&counter_mutex);
++counter;
pthread_mutex_unlock(&counter_mutex);
}
counter是由counter_mutex保护的。在更新counter的时候，必须要先持有counter_mutex，这样才能保证正确更新counter。另外锁的实现中，一般需要有内存barrier的指令，来禁止CPU的乱序执行。如果没有barrier的话，在CPU的指令执行过程中，counter的更新很可能发生在unlock之后。这些问题也不是今天的重点。
内存barrier指令只能保证CPU在barrier前的内存指令必须完成。但是如果在编译器将counter放到了寄存器中怎么办？比如在持有counter_mutex之前，对counter有读取的操作。那么编译器很可能会将counter在lock之前，就存到寄存器中。这样，在持有lock之后，counter因为之前已经读取到寄存器中了，这个++counter是否会直接对寄存器操作呢？如下面的代码：
#include
#include
#include
extern int counter;
extern pthread_mutex_t counter_mutex;
#define ASM_SEPERATOR __asm__ __volatile__ ("nop")
void add_counter(void)
{
/* 下面的代码对counter进行了读取操作，那么counter会被放入到寄存器中 */
int t = counter;
ASM_SEPERATOR;
printf("counter is %d\n", counter);
ASM_SEPERATOR;
/* 在前面的代码中，counter已经被放入到了寄存器中，那么下面的更新是否会直接更新该寄存器呢？ */
pthread_mutex_lock(&counter_mutex);
ASM_SEPERATOR;
++counter;
ASM_SEPERATOR;
pthread_mutex_unlock(&counter_mutex);
}
当想到这个问题的时候，心里升起一阵寒意。因为这样的代码肯定会存在于我们的工程中。在持有锁之前，对保护的资源进行读取的动作，这是一个很平常的行为。如果前面的读取动作导致该资源被放到寄存器中，岂不是导致锁失效了？难道在这种情况下，即使是读取动作也要加锁保护吗？如果假设为真的话，那么有bug的代码就太多了，那么早就报出很多问题了。所以这种使用方法应该是没有问题的。
还是让我们看一下反汇编吧：
00000000 :
extern pthread_mutex_t counter_mutex;
#define ASM_SEPERATOR __asm__ __volatile__ ("nop")
void add_counter(void)
{
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 28 sub $0x28,%esp
int t = counter;
6: a1 00 00 00 00 mov 0x0,%eax
b: 89 45 f4 mov %eax,-0xc(%ebp)
ASM_SEPERATOR;
e: 90 nop
printf("counter is %d\n", counter);
f: 8b 15 00 00 00 00 mov 0x0,%edx
15: b8 00 00 00 00 mov $0x0,%eax
1a: 89 54 24 04 mov %edx,0x4(%esp)
1e: 89 04 24 mov %eax,(%esp)
21: e8 fc ff ff ff call 22
ASM_SEPERATOR;
26: 90 nop
27: c7 04 24 00 00 00 00 movl $0x0,(%esp)
2e: e8 fc ff ff ff call 2f
pthread_mutex_lock(&counter_mutex);
33: 90 nop
ASM_SEPERATOR;
34: a1 00 00 00 00 mov 0x0,%eax
39: 83 c0 01 add $0x1,%eax
3c: a3 00 00 00 00 mov %eax,0x0
++counter;
41: 90 nop
ASM_SEPERATOR;
42: c7 04 24 00 00 00 00 movl $0x0,(%esp)
49: e8 fc ff ff ff call 4a
pthread_mutex_unlock(&counter_mutex);
4e: c9 leave
4f: c3 ret
红色部分的代码是将counter赋给t，这时counter已经被存入到eax中。而蓝色的代码是++counter。这里显示在counter进行自加的时候，是重新读取counter到寄存器中，然后再做自加，并没有直接利用前面的寄存器eax。
上面的汇编是没有使用优化选项的输出，下面是使用-O2优化的汇编结果：
Disassembly of section .text:
00000000 :
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 18 sub $0x18,%esp
6: 90 nop
7: a1 00 00 00 00 mov 0x0,%eax
c: c7 04 24 00 00 00 00 movl $0x0,(%esp)
13: 89 44 24 04 mov %eax,0x4(%esp)
17: e8 fc ff ff ff call 18
1c: 90 nop
1d: c7 04 24 00 00 00 00 movl $0x0,(%esp)
24: e8 fc ff ff ff call 25
29: 90 nop
2a: 83 05 00 00 00 00 01 addl $0x1,0x0
31: 90 nop
32: c7 04 24 00 00 00 00 movl $0x0,(%esp)
39: e8 fc ff ff ff call 3a
3e: c9 leave
3f: c3 ret
在t=counter时，依然是将counter放入到eax中，然后在将eax的值赋给t。而++counter的时候，干脆不用寄存器了，直接对内存进行加1的操作（x86支持对内存的加法操作）。
从汇编的结果上看，我之前的想到的问题有些杞人忧天了。即使counter在lock之前被存入某个寄存器，在自加的时候，仍然会重新读取，而不是直接使用那个寄存器。那么为什么编译器会产生这样的结果呢？因为使用了lock？比如lock的API中会有某个指令导致编译器生成这样的代码？我认为不可能。因为这样对编译器提出了非常过分的要求。因为编译的时候，编译器根本不会去检查调用的函数。在本例中，这个函数是pthread库函数，但是很多时候，这个函数甚至可以不存在。所以这个猜想肯定不对的。那么只有一个合理的解释了，因为counter是一个外部变量（非本函数内部定义）。编译器会假设该变量可能随时都会被外部更改，所以在任何时候，都需要重新读取到寄存器再使用。
这次我们干脆不是用全局变量，而是使用传入的参数：
#include
#include
#include
#define ASM_SEPERATOR __asm__ __volatile__ ("nop")
void add_counter(int *counter)
{
int t = *counter;
ASM_SEPERATOR;
printf("counter is %d %d\n", t, *counter);
ASM_SEPERATOR;
ASM_SEPERATOR;
++*counter;
ASM_SEPERATOR;
printf("counter is %d\n", *counter);
}
反汇编输出：
00000000 :
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 53 push %ebx
4: 83 ec 14 sub $0x14,%esp
7: 8b 5d 08 mov 0x8(%ebp),%ebx
a: 8b 03 mov (%ebx),%eax
c: 90 nop
d: 89 44 24 08 mov %eax,0x8(%esp)
11: 89 44 24 04 mov %eax,0x4(%esp)
15: c7 04 24 00 00 00 00 movl $0x0,(%esp)
1c: e8 fc ff ff ff call 1d
21: 90 nop
22: 90 nop
23: 8b 03 mov (%ebx),%eax
25: 83 c0 01 add $0x1,%eax
28: 89 03 mov %eax,(%ebx)
2a: 90 nop
2b: 89 44 24 04 mov %eax,0x4(%esp)
2f: c7 04 24 12 00 00 00 movl $0x12,(%esp)
36: e8 fc ff ff ff call 37
3b: 83 c4 14 add $0x14,%esp
3e: 5b pop %ebx
3f: 5d pop %ebp
40: c3 ret
蓝色部分仍然是自加的代码++*counter，和全局变量的counter一样，都是需要将外部变量的值读入到寄存器中，然后进行运算，再存入到寄存器中。
至此，我们得出结论，编译器在处理外部变量的时候，每次都需要重新读取到寄存器中，然后再使用。