Chinaunix

标题: 再论int变量赋值的原子性 [打印本页]
作者: freedon    时间: 2010-10-26 11:22
标题: 再论int变量赋值的原子性
前几天做项目，遇到了多线程读写全局int变量是否需要进行保护的问题，于是搜索到了四年前几位前辈对这个问题的精彩的讨论：
http://www.chinaunix.net/jh/23/804826.html

整篇帖子看下来，给我醍醐灌顶的感觉，实在是受益非浅；而这种做技术来不得一丝马虎的执着才是一个程序员所应该具备的执着。

唯一美中不足的，是整个帖了结束的时候，没有一个十分明确的结论到底int变量的多线程操作不加保护有没有危险,如果有危险，是在什么样的条件？而我遇到的问题很单一：CPU为ARM9，在内存没有对齐的情况下，会不会存在一个线程给一个int变量赋值没有结束而被另一个线程读走的危险？

以下是我的实验过程

实验代码：

  2. #include <stdio.h>
  3. #include <unistd.h>
  4. #include <pthread.h>
  5. struct STRU
  6. {
  7.     char a;
  8.     int  b;
  9. }__attribute__((packed));
  10. struct STRU v;

  12. void threadfun1(void)
  13. {
  14.     int i = 0;
  15.     while(1)
  16.     {
  17.         if(i%2 == 0)
  18.         {
  19.             v.b = 0x55555555;
  20.         }
  21.         else
  22.         {
  23.             v.b = 0xaaaaaaaa;
  24.         }
  25.         i++;
  26.     }      
  27. }

  29. void threadfun2(void)
  30. {   int i;
  31.    
  32.     while(1)
  33.     {   
  34.         i = v.b;
  35.         if((i != 0x55555555) && (i != 0xaaaaaaaa))
  36.         {   
  37.             printf("v.b = %x\n", i);
  38.         }
  39.     }
  40. }

  42. void main(void)
  43. {
  44.     pthread_t tidFun1;
  45.     pthread_t tidFun2;
  46.     pthread_create(&tidFun1, NULL, threadfun1, NULL);
  47.     pthread_create(&tidFun2, NULL, threadfun2, NULL);
  48.     while(1)
  49.     {
  50.         sleep(5);
  51.     }
  52. }
复制代码


如上，结构体struct STRU中的成员变量b，因为使用了宏__attribute__((packed))，所以采取的是字节对齐的方式而不是内存对齐的方式，用arm-linux-gcc来编译并反汇编，线程1的函数代码如下：

  2. 00008520 <threadfun1>:
  3.     8520:       e1a0c00d        mov     ip, sp
  4.     8524:       e92dd800        stmdb   sp!, {fp, ip, lr, pc}
  5.     8528:       e24cb004        sub     fp, ip, #4      ; 0x4
  6.     852c:       e24dd004        sub     sp, sp, #4      ; 0x4
  7.     8530:       e3a03000        mov     r3, #0  ; 0x0
  8.     8534:       e50b3010        str     r3, [fp, #-16]
  9.     8538:       e51b3010        ldr     r3, [fp, #-16]
  10.     853c:       e2233001        eor     r3, r3, #1      ; 0x1
  11.     8540:       e2033001        and     r3, r3, #1      ; 0x1
  12.     8544:       e20330ff        and     r3, r3, #255    ; 0xff
  13.     8548:       e3530000        cmp     r3, #0  ; 0x0
  14.     854c:       0a00000d        beq     8588 <threadfun1+0x68>
  15.     8550:       e59f2094        ldr     r2, [pc, #148]  ; 85ec <.text+0x1a8>
  16.     8554:       e3a03000        mov     r3, #0  ; 0x0
  17.     8558:       e3833055        orr     r3, r3, #85     ; 0x55
  18.     855c:       e5c23001        strb    r3, [r2, #1]
  19.     8560:       e3a03000        mov     r3, #0  ; 0x0
  20.     8564:       e3833055        orr     r3, r3, #85     ; 0x55
  21.     8568:       e5c23002        strb    r3, [r2, #2]
  22.     856c:       e3a03000        mov     r3, #0  ; 0x0
  23.     8570:       e3833055        orr     r3, r3, #85     ; 0x55
  24.     8574:       e5c23003        strb    r3, [r2, #3]
  25.     8578:       e3a03000        mov     r3, #0  ; 0x0
  26.     857c:       e3833055        orr     r3, r3, #85     ; 0x55
  27.     8580:       e5c23004        strb    r3, [r2, #4]
  28.     8584:       ea000014        b       85dc <threadfun1+0xbc>
  29.     8588:       e59f205c        ldr     r2, [pc, #92]   ; 85ec <.text+0x1a8>
  30.     858c:       e3a03000        mov     r3, #0  ; 0x0
  31.     8590:       e1e03003        mvn     r3, r3
  32.     8594:       e2033055        and     r3, r3, #85     ; 0x55
  33.     8598:       e1e03003        mvn     r3, r3
  34.     859c:       e5c23001        strb    r3, [r2, #1]
  35.     85a0:       e3a03000        mov     r3, #0  ; 0x0
  36.     85a4:       e1e03003        mvn     r3, r3
  37.     85a8:       e2033055        and     r3, r3, #85     ; 0x55
  38.     85ac:       e1e03003        mvn     r3, r3
  39.     85b0:       e5c23002        strb    r3, [r2, #2]
  40.     85b4:       e3a03000        mov     r3, #0  ; 0x0
  41.     85b8:       e1e03003        mvn     r3, r3
  42.     85bc:       e2033055        and     r3, r3, #85     ; 0x55
  43.     85c0:       e1e03003        mvn     r3, r3
  44.     85c4:       e5c23003        strb    r3, [r2, #3]
  45.     85c8:       e3a03000        mov     r3, #0  ; 0x0
  46.     85cc:       e1e03003        mvn     r3, r3
  47.     85d0:       e2033055        and     r3, r3, #85     ; 0x55
  48.     85d4:       e1e03003        mvn     r3, r3
  49.     85d8:       e5c23004        strb    r3, [r2, #4]
  50.     85dc:       e51b3010        ldr     r3, [fp, #-16]
  51.     85e0:       e2833001        add     r3, r3, #1      ; 0x1
  52.     85e4:       e50b3010        str     r3, [fp, #-16]
  53.     85e8:       eaffffd2        b       8538 <threadfun1+0x18>
  54.     85ec:       000109c5        andeq   r0, r1, r5, asr #19
复制代码


可以看到，对变量v.b的一个int赋值被分成了多条汇编语句，在目标机上运行，打印结果为以下多种结果
v.b = 55aaaaaa
v.b = 555555aa
v.b = aa555555
v.b = aaaa5555
......

由此可见，至少在arm9的CPU上，在非内存对齐的情况下，存在一个线程对全局的int变量赋值没有完成而被另一个线程读走，从而导致未知后果的可能性。

如果是在X86上又会如何？

以下是在X86上的汇编代码：
  1. 08048444 <threadfun1>:
  2. 8048444: 55 push %ebp
  3. 8048445: 89 e5 mov %esp,%ebp
  4. 8048447: 83 ec 10 sub $0x10,%esp
  5. 804844a: c7 45 fc 00 00 00 00 movl $0x0,0xfffffffc(%ebp)
  6. 8048451: 8b 45 fc mov 0xfffffffc(%ebp),%eax
  7. 8048454: 83 e0 01 and $0x1,%eax
  8. 8048457: 85 c0 test %eax,%eax
  9. 8048459: 75 0c jne 8048467 <threadfun1+0x23>
  10. 804845b: c7 05 15 97 04 08 55 movl $0x55555555,0x8049715
  11. 8048462: 55 55 55
  12. 8048465: eb 0a jmp 8048471 <threadfun1+0x2d>
  13. 8048467: c7 05 15 97 04 08 aa movl $0xaaaaaaaa,0x8049715
  14. 804846e: aa aa aa
  15. 8048471: 83 45 fc 01 addl $0x1,0xfffffffc(%ebp)
  16. 8048475: eb da jmp 8048451 <threadfun1+0xd>
复制代码


由上看到，X86对这种字节对齐的int变量也是只用了一条movl语句进行赋值，所以不会存在赋值到一半被另一个线程读走的情况，通过运行实验程序也证明了这个问题。

最后，虽然题目是“再论int变量赋值的原子性”，但如果其内容能达到前一帖子的百分之一二有用，我就心满意足了
作者: hdc1112    时间: 2010-10-26 11:44
好贴！ 试试代码去。。
作者: 32242132    时间: 2010-10-26 12:52
不错. 话说当初就是那个帖子把我吸引到了CU.
  我的工作和UNIX毫无关系.但编程的东西大家是相通的.
作者: jimmyixy    时间: 2010-10-26 16:39
比较完美的总结 学习
作者: davelv    时间: 2010-10-26 17:23
汇编指令是可以被中断的。
作者: hdc1112    时间: 2010-10-26 17:28
弱问，为什么我把程序down下来，运行了，结果没有输出？！。。。
作者: freedon    时间: 2010-10-27 17:36
弱问，为什么我把程序down下来，运行了，结果没有输出？！。。。
hdc1112 发表于 2010-10-26 17:28



你是什么CPU？如果是在X86上，是没有输出的，因为是X86上是一条汇编指令就完成赋值了，保证了原子性。
作者: shujunz    时间: 2010-10-27 18:16
好贴！收藏了
作者: davelv    时间: 2010-10-27 21:03
你是什么CPU？如果是在X86上，是没有输出的，因为是X86上是一条汇编指令就完成赋值了，保证了原子性。 ...
freedon 发表于 2010-10-27 17:36

你这是仅仅对于单CPU的情况，如果是多核你这条就不管用了，movl是访问的内存，在这个核心读取的时候那边可能正在修改。。
在我的机器上就输出了v.b=0;
作者: freedon    时间: 2010-10-28 08:58
你这是仅仅对于单CPU的情况，如果是多核你这条就不管用了，movl是访问的内存，在这个核心读取的时候那边可 ...
davelv 发表于 2010-10-27 21:03



    多核的没试过，或许会存在你说的那个问题吧。
不过你v.b=0的情况，并不是多核的问题，应该是线程2先于线程1运行所致。
作者: phy0077    时间: 2010-10-28 09:14
struct STRU v;
你的v你malloc出来试试，看看是什么样子
作者: smalloc    时间: 2010-10-28 09:20
这是2个与多处理器相关的帖子
http://linux.chinaunix.net/bbs/viewthread.php?tid=1145097
http://bbs.chinaunix.net/viewthread.php?tid=1583949
作者: hdc1112    时间: 2010-10-28 20:20
回复 7# freedon

哦。我知道了。我的是x86.难怪没有输出。呵呵。我还以为是线程没开启。
作者: 小i    时间: 2010-10-28 20:33
靠，真没想到当年我这么神勇呐~

不过当年说话是够冲的...

另外好多年没搞C这些底层的东西，真是忘的差不多了...
作者: smalloc    时间: 2010-10-28 20:55
回复 14# 小i


    现在在忙些啥呢
作者: 小i    时间: 2010-10-28 21:02
回复  小i


    现在在忙些啥呢
smalloc 发表于 2010-10-28 20:55



现在用Java给电信运营商搞管理平台...

话说，Java搞多线程真的很爽。封装的非常完善的类库，原子操作，线程同步什么的很轻松就搞定了~
作者: 小i    时间: 2010-10-28 21:21
另外lz的问题，我认为是这样的：
1. 对于ARM来说，int的赋值不是原子的。你知道，ARM是RISC的，RISC就是麻烦
2. 对于X86单核来说，int赋值是准原子的。虽然中间可能被打断，但不影响赋值结果。
3. 对于X86多核来说，int赋值可能不是原子的... 如果没对齐的话。你知道，X86是CISC的，CISC有时候也会自找麻烦
4. 对于ARM多核来说... 厄... 当我什么都没说好了...
作者: freedon    时间: 2010-10-29 18:29
struct STRU v;
你的v你malloc出来试试，看看是什么样子
phy0077 发表于 2010-10-28 09:14



    咋，有什么区别吗？
作者: freedon    时间: 2010-10-29 18:33
靠，真没想到当年我这么神勇呐~   

不过当年说话是够冲的...

另外好多年 ...
小i 发表于 2010-10-28 20:33



    当年“行不改名，做不改姓”的isjfk怎么改名叫小i啦？哈哈
作者: koolcoy    时间: 2010-10-29 23:00
另外lz的问题，我认为是这样的：
1. 对于ARM来说，int的赋值不是原子的。你知道，ARM是RISC的，RISC就是麻 ...
小i 发表于 2010-10-28 21:21


对于x86来说，只有对齐的mov指令才具有原子性
作者: 小i    时间: 2010-10-30 13:20
当年“行不改名，做不改姓”的isjfk怎么改名叫小i啦？哈哈
freedon 发表于 2010-10-29 18:33



isjfk打酱油去了。小i是来灌水的...
作者: chenzhanyiczy    时间: 2010-10-30 21:08
另外lz的问题，我认为是这样的：
1. 对于ARM来说，int的赋值不是原子的。你知道，ARM是RISC的，RISC就是麻 ...
小i 发表于 2010-10-28 21:21




2是错误的，就算int对齐了，也是不准确的，仍然可能是不原子的
作者: bo_00    时间: 2010-10-31 01:19
不错，学习了。

主要看，对应CPU的汇编，对int赋值，是多句还是单句。
作者: bo_00    时间: 2010-10-31 01:22
弱弱的问问

在arm9上，即便没对齐，，是否也会出现，赋值途中被读取的情况呢？
也就是说arm9上，无论对齐与否，对int的赋值汇编语句，都是多句的呢？



欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2