使用RTEMS信号量同步时，中断更新的变量会被编译器优化吗？

在你描述的RTEMS运行场景下，my_function 成功获取 tx_complete_semaphore 信号量后，是可以正常读到 isr_callback 写入的data=1的，不需要专门为data变量添加volatile限定。

• 很多刚接触RTOS的人容易被碎片化经验误导，觉得“只要是中断和其他上下文共用的全局变量，就必须加volatile”，其实这是对volatile作用的误解：volatile的唯一作用是阻止编译器对该变量的访问做无效优化，它本身不提供任何原子操作、内存序的并发保证，只在编译器识别不出跨上下文修改的场景下才是必需的。
• 你这里的两次data访问（isr里的写、my_function里的读）之间，夹了RTEMS的信号量同步原语，完全不需要volatile兜底：
  • 编译器层面：rtems_semaphore_obtain/rtems_semaphore_release、甚至你代码里调用的printf，都属于外部实现的函数，编译器看不到这些函数的内部逻辑，自然不会假设函数调用前后，全局静态变量data不会被其他上下文（比如硬件中断）修改。编译器会在这些函数调用的边界，强制把内存变量的值加载到寄存器、在函数返回后重新拉取内存中的最新值，绝不会把函数开头缓存的data=0的寄存器值直接拿来用。
  • 内核层面：RTEMS的信号量实现属于强同步原语，会在操作前后插入必要的内存屏障：isr里先执行data=1再释放信号量的执行顺序，不会被CPU乱序；等my_function成功获取到信号量、从obtain调用返回时，isr里对data的写入已经对当前上下文完全可见。
• 真正需要给data加volatile的场景，是没有任何内核同步点的纯轮询等待：比如你在my_function里写完data=0之后，直接写完全空转的轮询逻辑while(data == 0);，中间没有任何系统调用、库函数调用当同步点。这时候编译器会误以为当前上下文里没有修改data，直接把这个循环优化成永久卡死的死循环——这种场景下才需要用volatile强制编译器每次循环都从内存读data的最新值。

volatile从来不是解决并发访问的万能药：如果你的代码里没有信号量、临界区这类真正的同步原语，就算加了volatile，依然可能遇到CPU乱序执行、非原子读写导致的访问异常，没必要为了“保险”给所有跨上下文访问的变量都加上volatile——这只会带来不必要的内存访问开销，没有任何实际的并发保护作用。

内容的提问来源于stack exchange，提问作者LukesDiner