(Added explicit CC: to Paul)
Hello!
On Fri, 25 Oct 2019 21:32:35 +0800, Nan Xiao wrote:
> Hi Paul and perfbook members,
>
> Greetings from me!
>
> I have a question about 4.3.4.2 A Volatile Solution:
>
>> To summarize, the volatile keyword can prevent load tearing and store tearing in cases where the loads and stores are machine-sized and properly aligned. It can also prevent load fusing, store fusing, invented loads, and invented stores. However, although it does prevent the compiler from reordering volatile accesses with each other, it does nothing to prevent the CPU from reordering these accesses. Furthermore, it does nothing to prevent either compiler or CPU from reordering non-volatile accesses with each other or with volatile accesses. Preventing these types of reordering requires the techniques described in the next section.
>
> Does this summary apply for both C and C++? Or C only？
IIUC, it applies to both C and C++.
There is an article on LWN (Linux Weekly News) based on this section at:
https://lwn.net/Articles/793253/
The article and comments from readers there might be of your interest.
If your main concern is application code developed on modern C/C++ compilers
(C11/C++11 or later), it might be a good idea to use standard language
features which support concurrent code rather than to use volatile/volatile
casting. (There can be changes in C/C++ standards in future, though.)
Annotation of racy accesses by READ_ONCE()/WRITE_ONCE() to prevent
compiler optimizations can be seen as abusing of volatile from the
view point of compiler developers. But it survives generations of
compilers (with occasional regression reported as bugs in compiler
optimization).
Thanks, Akira
>
> Thanks very much in advance!
>
> Best Regards
> Nan Xiao
>
