娘的， 似乎犯错误了----技术帖

zylthinking

@塑料袋 @tempname2 @帅绝人寰 帮我看看， 搞不定了

1. #define lock(lkp) do{  \
   
2.     while(!__sync_bool_compare_and_swap(lkp, 0, 1)){    \
   
3.         sched_yield();  \
   
4.     }   \
   
5. }while(0)
   
6. 
   
7. #define try_lock(lkp) ({   \
   
8.     (__sync_bool_compare_and_swap(lkp, 0, 1) ? 0 : -1);   \
   
9. })
   
10. 
    
11. #define unlock(lkp) do{    \
    
12.     *(lkp) = 0;  \
    
13. }while(0)
    

复制代码

lkp 在不是 volatile 的情况下， 是不是不安全？
一直以来都是这么用的， 似乎也问题， 今天突然觉得不安了
主要是 unlock 直接就是  *(lkp) = 0; 行不行？

1。 似乎不能防止编译器重拍指令， 比如

int lk = 0;
int n = 0;
lock(&lk);
++n;
unlock(&lk);

编译器有可能重排成

lock(&lk);
unlock(&lk);
++n;

2。 就算不重拍， 那么乱序呢？
执行完 unlock(&lk) 后会是怎么一种情景？
我的理解是 ++n 肯定已经执行完了， 但是可能还在 load/store unit 里面， 没有更新到寄存器
那么这个时候发生线程切换， 再次读此值， 应该会直接从 load/store unit 内直接读取到， 因此不会有太大问题； 但还是需要 @塑料袋 确认一下，
关键是如果 *(lkp) = 0; 已经进入了 load/store unit, 则可以保证 ++n 至少在 load/store unit 内， 或者已经到了寄存器中？？？

另外， 如果另一个线程读 n 时， 产生的汇编应该是从内存读， 那么它怎么知道内存中某单元中的值已经在 load/store unit 中了？
似乎首先要确认的是 ++n 的结果在 load/store unit 中时， 写的目标到底是存储器还是寄存器；
如果是寄存器， 也就是 n 被优化到寄存器中了， 那么CPU 还能直接从 load/store unit 中读吗？ 但如果不从其中读而直接读内存， 那读出的就是一个错误的值

3。 另一个是C层面的问题了@OwnWaterloo  @starwing83  @幻の上帝

文件1：
volatile int n = 0;
文件2:
extern int n;
++n;

那么在文件2中， n 会不会还会当作 volatile 来对待
不知道会不会又是所谓 UB 行为， 但 gcc 4.2 这样做是可以的， 甚至连一个警告都没有

群雄逐鹿中原

C版有这样的帖子，才能回归理性。

zylthinking

群雄逐鹿中原 发表于 2012-06-27 10:46
C版有这样的帖子，才能回归理性。

专家不死， 乱象不止
你要相信我

bruceteen

3。我猜 不会当作 volatile 来对待
在不知道为 volatile 时就已经编译好了
但link时应当报错，因为 volatile int n 和 int n 不应该弄成一样的名字

群雄逐鹿中原

写错，删除

塑料袋

ARM体系的atomic.h中，更能反映锁的本质是什么。 x86的atomic.h则很难看出来。

所有不带返回值的atomic_xxx，都是__asm__ __volatile__()内原子的修改变量
所有带返回值的atomic_xxx，都是smp_mb(); __asm__ __volatile__() ; smp_mb();

获得锁的本意是 ： 原子的置位锁变量； 内存屏障，用来克服乱序影响，保证对受保护数据的操作发生在置位锁变量之后。
释放锁的本意是 ： 内存屏障，用来克服乱序影响，保证对受保护数据的操作发生在清零锁变量之前； 原子的清零锁变量；

kernel中只有这种带返回值的atomic_xxx可以充作锁来用，它不仅有两个smp_mb()；而且有一个返回值，能判断出来是否成功的获得了锁。


至于两个文件都用了n，但只有1个说n是volatile，怎么可能另一个还认为其是volatile呢，这是不可能的。

zylthinking

塑料袋 发表于 2012-06-27 11:34
ARM体系的atomic.h中，更能反映锁的本质是什么。 x86的atomic.h则很难看出来。

所有不带返回值的atomic_ ...

大哥， 红色的字体是我最关注的； 你要具体些啊

塑料袋

到了load stor unit，肯定是写内存啊，写寄存器根本不过这里。

而且不管怎么乱序，CPU看自己的读写，必须是顺序的，这个是大原则。

乱序造成的主要结果，是其他CPU看本地CPU，看到的是乱序结果。

tempname2

回复 6# 塑料袋

为什么用户态鲜有看到这些顾虑？

乱序的CPU会打破老用户态代码的兼容性么？

除了显然的依赖外，乱序有其它constraint么？编译器的静态重排比较好接受，CPU乱序太无厘头了。



另外，@帅绝人寰表示，新闻版不开，他不再参与技术讨论

zylthinking

塑料袋 发表于 2012-06-27 11:42
到了load stor unit，肯定是写内存啊，写寄存器根本不过这里。

而且不管怎么乱序，CPU看自己的读写，必须 ...

这才是醍醐灌顶
那么

int n = 0;
int lk = 0;

thread1:
fron 0 to 99
lock(&lk);
++n;
unlock(&lk);

thread2:

fron 0 to 99
lock(&lk);
++n;
unlock(&lk);

并不能保证 n 的终值 200 了？
因为不能避免 n 被优化到寄存器内
要保证， 必须 unlock 是一个内存栅栏才行