news 2026/4/15 8:36:56

C语言中的volatile到底有什么用?

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
C语言中的volatile到底有什么用?

嵌入式C编程时,有一个奇怪的关键字volatile,这到底有什么用呢?

volatile与编译器

首先来看这样一段代码:

int busy = 1; void wait() { while(busy) { ; }}

编译一下,注意,这里使用O2优化

让我们仔细看看生成的这段汇编:

wait: mov eax, DWORD PTR busy[rip].L2: test eax, eax jne .L2 retbusy: .long 1

其中L2这一段即为while循环,这段指令是经过编译器优化的,可以看到,决定能否跳出循环是通过检查寄存器eax来完成的,而没有检查变量busy所在内存的真实内容。

注意,对于这段代码来说这里的优化是正确的,但问题是如果还有其它代码修改了变量busy,那么这里的优化会导致其它代码对变量busy的修改根本就不能生效,就像这样:

int busy = 1;// 该函数在A线程中执行void wait() { while(busy) { ; }}// 该函数在B线程中执行void signal() { busy = 0;}

如果wait函数中while循环对应的机器指令仅仅从寄存器中读取数据那么即使B线程的signal函数修改了busy变量也不能让wait函数从循环中跳出来。

如果你对busy变量使用volatile修饰,生成的指令就变成这样了:

wait:.L2: mov eax, DWORD PTR busy[rip] test eax, eax jne .L2 retbusy: .long 1

注意看此时L2这一段,每次都从busy变量所在的内存中读取数据并存放在eax,然后再去判断,这样就能确保每次都能读取到busy变量的最新值。

实际上你可以把寄存器eax当做busy所在内存的cache,当cache(寄存器)和内存中的数据一致时不会有任何问题,但当cache与内存中的数据不一致时(也就是内存已被更新但cache保存的还是旧数据),程序的运行往往出乎预料。

除了多线程的例子,还有一类就是signal handler以及硬件修改该变量(用C语言与硬件交互式时经常遇到),如果编译器生成文章开头那样的指令那么等待线程将检测不到signal handler或者硬件对变量的修改。

因此在这里我们需要告诉编译器:“不要耍小聪明,不要只从寄存器中读数据,这个变量可能在其它地方已经被修改了,使用时从内存中获取最新数据”。

现在是时候简单总结一下了,volatile仅仅阻止编译器试图去优化对变量的读取操作

volatile与多线程

一定要注意volatile仅仅确保变量的可见性,但和变量的原子访问没有半毛钱关系,这是两个完全不同的任务

假设有一个非常复杂的结构体struct foo:

struct data { int a; int b; int c; ...};volatile struct data foo; void thread1() { foo.a = 1; foo.b = 2; foo.c = 3; ...}void thread2() { int a = foo.a; int b = foo.b; int c = foo.c; ...}

你仅仅用volatile去修饰变量foo只是确保了当该变量被thread1修改后我们能在thread2中读取到最新值,但是这解决不了多线程并发读写需要原子访问foo的问题

确保变量原子性访问一般都采用锁,当使用锁时,锁本身就包含了volatile提供能力,即,确保变量的可见性,因此当使用锁时没有必要使用volatile。

volatile与memory order

有的同学可能会想如果我想用volatile修饰的变量没有那么复杂,仅仅是一个int,就像这样:

volatileint busy = 0;

A线程读取busy变量,B线程更新busy变量,当A检测到busy变化后执行特定操作,这样可行吗?既然通过volatile修饰后可以确保每次都从内存中读取busy,那么应该可以这样使用吧。

然而,计算机在概念上可能相对简单些,但在工程实践中是复杂的。

我们知道由于CPU与内存之间的速度差异非常大,CPU与内存之间有一层cache,CPU其实并没有直接读取内存,cache的存在会让问题复杂起来,限于篇幅与本文主题这里不再展开。

为优化内存读写,CPU可能会对内存读写操作进行指令重排,reordering,带来的后果就是:假设在线程1中先后执行第N行代码与第N+1行代码,但在线程2看来却是第N+1行代码先生效,假设X的初始值为0,Y的初始值为1:

线程1 线程2X = 10 if (!busy)busy = 0; Y = X;

当线程2检测到busy为0后读取X的值,此时读取到的X值可能为0。

为解决这一问题,我们需要的不是volatile,volatile解决不了reordering问题,我们需要的是内存屏障,memory barrier。

内存屏障是一类机器指令,该指令对处理器在该屏障指令之前与之后的内存操作进行了限制,确保不会出现重排问题。

而内存屏障带来的效果依然能够涵盖volatile提供的功能,因此也不需要volatile。

------------END------------

不靠 MCU,用 FPGA + DAC 实现可调信号源

嵌入式多线程从"能跑"到"稳定"的关键一步!

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/4/14 6:26:59

Agentic AI实践指南|秘籍七:Agent可观测性评估

本系列文章基于在多个项目中积累的Agent应用构建经验,分享Agentic AI基础设施实践经验内容,帮助您全面深入地掌握Agent构建的基本环节。上篇文章系统介绍了Agent质量评估相关内容。本篇文章将探讨Agent可观测性的核心要素、实现方式和最佳实践&#xff0…

作者头像 李华
网站建设 2026/4/10 8:42:41

16、Git 高级操作:改写提交历史

Git 高级操作:改写提交历史 1. 重置操作 在某些情况下,直接提交可能会使提交图变得混乱,此时应确定正确的状态并进行重置。以下是两种重置方式: - 硬重置 :使用 git reset --hard 命令,它会将当前分支的 HEAD 引用、索引和工作目录都重置到指定的提交。例如: $…

作者头像 李华
网站建设 2026/4/10 21:41:55

STM32 JLink烧录时序与流程深度剖析

深入理解STM32的JLink烧录机制:从物理连接到Flash写入的全过程解析在嵌入式开发中,固件烧录是产品调试、量产和维护的关键一步。尽管大多数工程师已经习惯使用Keil或STM32CubeProgrammer点击“Download”完成程序下载,但当遇到“无法连接目标…

作者头像 李华
网站建设 2026/4/9 11:26:59

25、Git 补丁与钩子深度解析

Git 补丁与钩子深度解析 1. Git 补丁相关内容 1.1 补丁作者和提交者信息 在 Git 中,补丁的作者和作者日期是根据原始提交和补丁来确定的,而提交者的数据则反映了应用补丁并将其提交到当前分支和仓库的操作。 1.2 糟糕补丁的问题 在全球多个分布式仓库中创建健壮且相同的…

作者头像 李华
网站建设 2026/4/14 8:51:43

11、Windows 8 应用开发:界面、数据绑定与生命周期管理

Windows 8 应用开发:界面、数据绑定与生命周期管理 1. 可视化组件与按需用户界面 在 Windows 8 应用开发中,可视化组件能够覆盖众多常见场景。你可以从第三方供应商、开源项目以及博客文章中找到更多现成的 Windows 应用商店可视化组件。随着对 Windows 8 开发的逐渐熟悉,…

作者头像 李华