Why the "volatile" type class should not be used
------------------------------------------------
C programmers have often taken volatile to mean that the variable could be
changed outside of the current thread of execution; as a result, they are
sometimes tempted to use it in kernel code when shared data structures are
being used. In other words, they have been known to treat volatile types
as a sort of easy atomic variable, which they are not. The use of volatile in
kernel code is almost never correct; this document describes why.
The key point to understand with regard to volatile is that its purpose is
to suppress optimization, which is almost never what one really wants to
do. In the kernel, one must protect shared data structures against
unwanted concurrent access, which is very much a different task. The
process of protecting against unwanted concurrency will also avoid almost
all optimization-related problems in a more efficient way.
Like volatile, the kernel primitives which make concurrent access to data
safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent
unwanted optimization. If they are being used properly, there will be no
need to use volatile as well. If volatile is still necessary, there is
almost certainly a bug in the code somewhere. In properly-written kernel
code, volatile can only serve to slow things down.
Consider a typical block of kernel code:
spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);
If all the code follows the locking rules, the value of shared_data cannot
change unexpectedly while the_lock is held. Any other code which might
want to play with that data will be waiting on the lock. The spinlock
primitives act as memory barriers - they are explicitly written to do so -
meaning that data accesses will not be optimized across them. So the
compiler might think it knows what will be in shared_data, but the
spin_lock() call, since it acts as a memory barrier, will force it to
forget anything it knows. There will be no optimization problems with
accesses to that data.
If shared_data were declared volatile, the locking would still be
necessary. But the compiler would also be prevented from optimizing access
to shared_data _within_ the critical section, when we know that nobody else
can be working with it. While the lock is held, shared_data is not
volatile. When dealing with shared data, proper locking makes volatile
unnecessary - and potentially harmful.
The volatile storage class was originally meant for memory-mapped I/O
registers. Within the kernel, register accesses, too, should be protected
by locks, but one also does not want the compiler "optimizing" register
accesses within a critical section. But, within the kernel, I/O memory
accesses are always done through accessor functions; accessing I/O memory
directly through pointers is frowned upon and does not work on all
architectures. Those accessors are written to prevent unwanted
optimization, so, once again, volatile is unnecessary.
Another situation where one might be tempted to use volatile is
when the processor is busy-waiting on the value of a variable. The right
way to perform a busy wait is:
while (my_variable != what_i_want)
cpu_relax();
The cpu_relax() call can lower CPU power consumption or yield to a
hyperthreaded twin processor; it also happens to serve as a compiler
barrier, so, once again, volatile is unnecessary. Of course, busy-
waiting is generally an anti-social act to begin with.
There are still a few rare situations where volatile makes sense in the
kernel:
- The above-mentioned accessor functions might use volatile on
architectures where direct I/O memory access does work. Essentially,
each accessor call becomes a little critical section on its own and
ensures that the access happens as expected by the programmer.
- Inline assembly code which changes memory, but which has no other
visible side effects, risks being deleted by GCC. Adding the volatile
keyword to asm statements will prevent this removal.
- The jiffies variable is special in that it can have a different value
every time it is referenced, but it can be read without any special
locking. So jiffies can be volatile, but the addition of other
variables of this type is strongly frowned upon. Jiffies is considered
to be a "stupid legacy" issue (Linus's words) in this regard; fixing it
would be more trouble than it is worth.
- Pointers to data structures in coherent memory which might be modified
by I/O devices can, sometimes, legitimately be volatile. A ring buffer
used by a network adapter, where that adapter changes pointers to
indicate which descriptors have been processed, is an example of this
type of situation.
For most code, none of the above justifications for volatile apply. As a
result, the use of volatile is likely to be seen as a bug and will bring
additional scrutiny to the code. Developers who are tempted to use
volatile should take a step back and think about what they are truly trying
to accomplish.
Patches to remove volatile variables are generally welcome - as long as
they come with a justification which shows that the concurrency issues have
been properly thought through.
NOTES
-----
[1] http://lwn.net/Articles/233481/
[2] http://lwn.net/Articles/233482/
CREDITS
-------
Original impetus and research by Randy Dunlap
Written by Jonathan Corbet
Improvements via comments from Satyam Sharma, Johannes Stezenbach, Jesper
Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
Richter.
多线程编程中什么情况下需要加 volatile？
网上说 volatile 有一种使用是作为「多线程被几个任务共享变量的修饰符」。但是我看过很多代码多线程临界区里面变量声明时并没有加 volatile。比方说印象中整个 muduo 网络库好像就 atomicInt 有 volatile；nginx 中一些时间的表示都用了 volatile。
是否意味着在可重入（线程安全且不互斥使用）函数的访问中的变量才需要用 volatile 呢？但是似乎有些代码就是拿了个全局的 int 之类的当做多线程的标识变量，不加 volatile 可行么？
总之
相关问题：
C++多线程有必要加volatile么？ - C++11
是否意味着在可重入（线程安全且不互斥使用）函数的访问中的变量才需要用 volatile 呢？但是似乎有些代码就是拿了个全局的 int 之类的当做多线程的标识变量，不加 volatile 可行么？
总之
- 多线程编程中什么情况下需要加 volatile？
- 如果说 volatile 关键字对多线程无用，那为什么类似 muduo 和 nginx 的库都有用到呢？
相关问题：
C++多线程有必要加volatile么？ - C++11
按投票排序按时间排序
21 个回答
知乎用户 ，一本正经的哈士奇请各位大师回答问题的时候谨言慎行，不要做出错误的误导，，
//---------------------------------------------------------------------
volatile并不能解决线程问题
线程问题大致是，其他的线程有意无意的修改了本线程所要使用的数据，但是本线程没有预料到这种修改，于是产生的这种问题。
为了不被多线程问题所困扰，
我一般用__declspec(thread)来修饰变量的，
（ps：xp之前支持的并不好）
或者系统提供的tls机制（其实__declspec(thread)的实现也是tls）
或者自己写一个类似与tls的东西..
至于volatile 嘛.. 其实不开启优化的情景下，加不加是没区别的（vs中都是volatile的。）,,
然而优化开启后，volatile生效后，也并不能避免多线程中切换线程的时候引起的麻烦
被volatile关键字所修饰的变量，
只不过是每次使用的时候，都必须从
(原始的)(存储变量内容的) 内存 中读取数据、、
举个例子。
代码如下：
main编译之后，汇编代码如下：
ii_main编译之后，汇编代码如下：
我们看到，在main中用volatile修饰的i变量，每次操作这个volatile变量的时候，
编译器都会从 存储 “i”变量的 内存 中从新读取数据，，
这样的做法好处是，如果别的线程更新修改了 存储 “i”变量的 内存
那么这个线程就能第一时间响应，得到更新的结果。
因为每一次都是使用都是 从 存储 “i”变量的 内存 中从新读取数据，，
这样做有好有坏，有利有弊，编程的时候考虑进去就行了
而我们反观ii_main中的（没有被volatile的）反汇编代码，
至始至终就是把数据存储在寄存器里的
这样做的好处是减少了内存读取次数，让程序大大加快，
不过不能第一时间响应别的线程的结果就是了，，
end;
/////////////////////////////////////////////////////////////////////////////////////////////////
/*
自己实现的tls功能，用着感觉还可以
//---------------------------------------------------------------------
volatile并不能解决线程问题
线程问题大致是，其他的线程有意无意的修改了本线程所要使用的数据，但是本线程没有预料到这种修改，于是产生的这种问题。
为了不被多线程问题所困扰，
我一般用__declspec(thread)来修饰变量的，
（ps：xp之前支持的并不好）
或者系统提供的tls机制（其实__declspec(thread)的实现也是tls）
或者自己写一个类似与tls的东西..
至于volatile 嘛.. 其实不开启优化的情景下，加不加是没区别的（vs中都是volatile的。）,,
然而优化开启后，volatile生效后，也并不能避免多线程中切换线程的时候引起的麻烦
被volatile关键字所修饰的变量，
只不过是每次使用的时候，都必须从
(原始的)(存储变量内容的) 内存 中读取数据、、
举个例子。
代码如下：
main编译之后，汇编代码如下：
ii_main编译之后，汇编代码如下：
我们看到，在main中用volatile修饰的i变量，每次操作这个volatile变量的时候，
编译器都会从 存储 “i”变量的 内存 中从新读取数据，，
这样的做法好处是，如果别的线程更新修改了 存储 “i”变量的 内存
那么这个线程就能第一时间响应，得到更新的结果。
因为每一次都是使用都是 从 存储 “i”变量的 内存 中从新读取数据，，
这样做有好有坏，有利有弊，编程的时候考虑进去就行了
而我们反观ii_main中的（没有被volatile的）反汇编代码，
至始至终就是把数据存储在寄存器里的
这样做的好处是减少了内存读取次数，让程序大大加快，
不过不能第一时间响应别的线程的结果就是了，，
end;
/////////////////////////////////////////////////////////////////////////////////////////////////
/*
自己实现的tls功能，用着感觉还可以
#include"stdafx.h"
#include <tlhelp32.h>
CRITICAL_SECTION dt_CRITICAL_SECTION;
/*
InitializeCriticalSection(&dt_CRITICAL_SECTION);找个时机初始化“边界锁”，比如dll初始化的时候
DeleteCriticalSection(&dt_CRITICAL_SECTION);找个时机释放“边界锁”，比如dll被释放掉的时候
GetProcessThread 并无卵用，就是粘贴过来当个模板
td_my_ThreadData 中threadid是线程tid，data是线程相关的数据，
void* GetThreadBufferPtr() 获取线程相关数据
SetThreadBufferPtr(void*) 设置线程相关数据
主要思路是把线程和线程数据格式化成字符串"<tid>:[data];"
例如下面这样
"<0x00000001>:[0x00000002];"
0x00000001是tid
0x00000002是数据
然后把"<tid>:[data];"直接拼接到static char* pt_lst = 0;中
static DWORD dt_BufSize_ = 1024; 是pt_lst的内存大小，
实现tid自动更新，pt_lst内存自动扩展等功能
/*
使用时候请注意对GetThreadBufferPtr返回的结果做有效性校验，比如返回的内存指针是否有效什么的。
因为这段代码并不包括监控指针有效性的功能
*/
*/
DWORD GetProcessThread(DWORD th32ProcessID,DWORD th32ThreadID) //进程的ID
{
HANDLE hThreadSnap;
THREADENTRY32 th32;
hThreadSnap = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, th32ProcessID);
if (hThreadSnap == INVALID_HANDLE_VALUE)
{
return 0;
}
th32.dwSize = sizeof(THREADENTRY32);
if (!Thread32First(hThreadSnap, &th32))
{
CloseHandle(hThreadSnap);
return 0;
}
do
{
if (th32.th32OwnerProcessID == th32ProcessID)
{
printf("ThreadID: %ld
", th32.th32ThreadID); //显示找到的线程的ID
if (th32ThreadID == th32.th32ThreadID)
{
return th32.th32ThreadID;
}
}
} while (Thread32Next(hThreadSnap, &th32));
CloseHandle(hThreadSnap);
return 0;
}
char test[] = { "<0x00000000>:[0x00000000];" };
typedef struct td_my_ThreadData
{
//char data[26];
char data01[1];
char threadid[10];
char data02[3];
char data[10];
char data03[2];
}td_my_ThreadData,*pttd_my_ThreadData;
pttd_my_ThreadData QueryThreadData_ptr(char* ThreadDataList, DWORD dwThread)
{
if (dwThread == 0 || ThreadDataList == 0)
{
return 0;
}
char cpThread[26];
memset(cpThread, 0, 26);
sprintf_s(cpThread, 26, "<0x%08X>", dwThread