volatile
关键字有什么作用?在C ++中它解决了什么问题?
就我而言,我从来没有故意需要它。
如果您从内存中的某个位置读取,例如,一个完全独立的进程/设备/可能写入的内容,则需要使用volatile
。
我曾经在直接C的多处理器系统中使用双端口ram。我们使用硬件管理的16位值作为信号量来知道其他人何时完成。基本上我们这样做了:
void waitForSemaphore()
{
volatile uint16_t* semPtr = WELL_KNOWN_SEM_ADDR;/*well known address to my semaphore*/
while ((*semPtr) != IS_OK_FOR_ME_TO_PROCEED);
}
如果没有volatile
,优化器会认为循环无用(这个人永远不会设置值!他很疯狂,摆脱那些代码!)并且我的代码将在没有获得信号量的情况下继续进行,从而导致以后出现问题。
除了按预期使用它之外,在(模板)元编程中使用volatile。它可用于防止意外过载,因为volatile属性(如const)参与重载决策。
template <typename T>
class Foo {
std::enable_if_t<sizeof(T)==4, void> f(T& t)
{ std::cout << 1 << t; }
void f(T volatile& t)
{ std::cout << 2 << const_cast<T&>(t); }
void bar() { T t; f(t); }
};
这是合法的;两个重载都可以调用,并且几乎完全相同。 volatile
超载中的演员是合法的,因为我们知道bar无论如何都不会通过非挥发性的T
。然而,volatile
版本严格地更糟,因此如果非易失性f
可用,则永远不会在重载分辨率中选择。
请注意,代码实际上从不依赖于volatile
内存访问。
volatile
关键字旨在防止编译器对可能以编译器无法确定的方式更改的对象应用任何优化。
声明为volatile
的对象在优化中被省略,因为它们的值可以随时由当前代码范围之外的代码更改。系统始终从内存位置读取volatile
对象的当前值,而不是将其值保存在请求点的临时寄存器中,即使前一条指令要求来自同一对象的值也是如此。
考虑以下情况
1)由范围外的中断服务例程修改的全局变量。
2)多线程应用程序中的全局变量。
如果我们不使用volatile限定符,可能会出现以下问题
1)打开优化时,代码可能无法按预期工作。
2)启用和使用中断时,代码可能无法正常工作。
Volatile: A programmer’s best friend
https://en.wikipedia.org/wiki/Volatile_(computer_programming)
除了volatile关键字用于告诉编译器不优化对某个变量的访问(可以通过线程或中断例程修改)之外,它还可以用于删除一些编译器错误 - 是的,它可以是---。
例如,我在嵌入式平台上工作的是编译器对变量值进行了一些错误的分析。如果代码没有优化,程序将运行正常。通过优化(这是真正需要的,因为它是一个关键的例程)代码将无法正常工作。唯一的解决方案(虽然不是很正确)是将'faulty'变量声明为volatile。
即使没有volatile
关键字,您的程序似乎也能正常工作?也许这就是原因:
如前所述,volatile
关键字有助于处理类似的情况
volatile int* p = ...; // point to some memory
while( *p!=0 ) {} // loop until the memory becomes zero
但是,一旦调用外部或非内联函数,似乎几乎没有效果。例如。:
while( *p!=0 ) { g(); }
然后有或没有volatile
几乎产生相同的结果。
只要g()可以完全内联,编译器就可以看到正在进行的所有事情,因此可以进行优化。但是当程序调用一个编译器无法看到正在发生的事情的地方时,编译器不再需要做出任何假设是不安全的。因此,编译器将生成始终直接从内存中读取的代码。
但要注意当天,当你的函数g()变为内联时(由于显式更改或由于编译器/链接器的聪明),如果你忘记了volatile
关键字,你的代码可能会中断!
因此,我建议添加volatile
关键字,即使您的程序似乎没有。它使意图在未来的变化方面更清晰,更健壮。
在C的早期,编译器会将读取和写入左值作为内存操作的所有操作解释为与代码中出现的读写相同的序列。如果编制者获得一定程度的自由来重新订购和整合运营,那么在许多情况下效率可以大大提高,但是存在问题。甚至操作通常仅按某种顺序指定,因为有必要按某种顺序指定它们,因此程序员选择了许多同样好的替代方案中的一种,但情况并非总是如此。有时某些操作以特定顺序发生是很重要的。
确切地说,排序的哪些细节很重要,具体取决于目标平台和应用领域。标准选择了一个简单的模型,而不是提供特别详细的控制:如果使用不合格volatile
的左值进行一系列访问,编译器可以根据需要重新排序和合并它们。如果使用volatile
限定的左值进行操作,则质量实现应提供针对其预期平台和应用程序字段的代码可能需要的任何其他排序保证,而不必要求使用非标准语法。
不幸的是,许多编制者选择提供标准规定的最低限度保证,而不是确定程序员需要什么样的保证。这使得volatile
的用处远没有它应有的那么多。例如,在gcc或clang上,需要实现基本“切换互斥锁”的程序员[已经获取并释放互斥锁的任务在其他任务完成之前不会再执行此操作]必须执行一个四件事:
volatile
- 如果在获取互斥锁之后和释放互斥锁之前发生所有访问,则不应该这样做。register
都是volatile
一样。相比之下,当使用更适合系统编程的更高质量的编译器(例如icc)时,可以有另一种选择:
volatile
限定的写入。获取一个基本的“切换互斥锁”需要一个volatile
读取(看它是否准备就绪),并且不应该要求volatile
写入(另一方不会尝试重新获取它直到它被交还)但必须执行无意义的volatile
写入仍然比gcc或clang下可用的任何选项更好。
我应该提醒您的一个用途是,在信号处理函数中,如果要访问/修改全局变量(例如,将其标记为exit = true),则必须将该变量声明为“volatile”。
在开发嵌入式系统或设备驱动程序时需要volatile
,您需要读取或写入内存映射的硬件设备。特定设备寄存器的内容可能随时更改,因此您需要使用volatile
关键字来确保编译器不会优化此类访问。
一些处理器具有超过64位精度的浮点寄存器(例如,没有SSE的32位x86,参见Peter的评论)。这样,如果对双精度数运行多个操作,实际上得到的答案要比将每个中间结果截断为64位时更高。
这通常很好,但这意味着根据编译器分配寄存器的方式和优化,您将在完全相同的输入上对完全相同的操作产生不同的结果。如果需要一致性,则可以使用volatile关键字强制每个操作返回内存。
它对于一些没有代数意义但减少浮点误差的算法也很有用,例如Kahan求和。代数上它是一个nop,因此除非某些中间变量是易失性的,否则它往往会被错误地优化出来。
来自Dan Saks的“挥发性如诺”文章:
(...)易失性物体的价值可能会自发变化。也就是说,当你声明一个对象是volatile时,你告诉编译器该对象可能会改变状态,即使程序中的任何语句都没有改变它。“
以下是关于volatile
关键字的三篇文章的链接:
在实现无锁数据结构时,您必须使用volatile。否则,编译器可以自由地优化对变量的访问,这将改变语义。
换句话说,volatile告诉编译器访问此变量必须对应于物理内存读/写操作。
例如,这是在Win32 API中声明InterlockedIncrement的方式:
LONG __cdecl InterlockedIncrement(
__inout LONG volatile *Addend
);
我在20世纪90年代早期使用的大型应用程序包含使用setjmp和longjmp的基于C的异常处理。 volatile的关键字对于需要在作为“catch”子句的代码块中保留的变量是必要的,以免这些变量存储在寄存器中并被longjmp消灭。
在标准C中,使用volatile
的地方之一是信号处理程序。实际上,在标准C中,您可以安全地在信号处理程序中执行的操作是修改volatile sig_atomic_t
变量,或快速退出。事实上,AFAIK,它是标准C中唯一需要使用volatile
来避免未定义行为的地方。
ISO/IEC 9899:2011 §7.14.1.1 The
signal
function¶5如果信号的出现不是调用
abort
或raise
函数的结果,那么如果信号处理程序引用具有静态或线程存储持续时间但不是无锁定原子对象的任何对象,则行为是未定义的。声明为volatile sig_atomic_t
的对象的值,或者信号处理程序调用标准库中除abort
函数,_Exit
函数,quick_exit
函数或signal
函数之外的任何函数,第一个参数等于对应于的信号编号导致调用处理程序的信号。此外,如果对signal
函数的这种调用导致SIG_ERR返回,则errno
的值是不确定的.252)252)如果异步信号处理程序生成任何信号,则行为未定义。
这意味着在标准C中,您可以写:
static volatile sig_atomic_t sig_num = 0;
static void sig_handler(int signum)
{
signal(signum, sig_handler);
sig_num = signum;
}
而不是其他。
POSIX对于你在信号处理程序中可以做的事情要宽容得多,但仍有局限性(其中一个限制是标准I / O库 - printf()
等 - 无法安全使用)。
为嵌入式开发,我有一个循环,它检查可以在中断处理程序中更改的变量。如果没有“volatile”,循环就会变成noop - 就编译器而言,变量永远不会改变,因此它会优化检查。
同样的事情适用于在更传统的环境中可能在不同线程中更改的变量,但是我们经常进行同步调用,因此编译器不是那么自由的优化。
我已经在调试版本中使用它,当编译器坚持优化我希望能够在逐步执行代码时看到的变量。