* Question about volatile usage
@ 2019-10-25 13:32 Nan Xiao
2019-10-27 2:45 ` Akira Yokosawa
0 siblings, 1 reply; 4+ messages in thread
From: Nan Xiao @ 2019-10-25 13:32 UTC (permalink / raw)
To: perfbook
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?
Thanks very much in advance!
Best Regards
Nan Xiao
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about volatile usage
2019-10-25 13:32 Question about volatile usage Nan Xiao
@ 2019-10-27 2:45 ` Akira Yokosawa
2019-10-27 17:11 ` Paul E. McKenney
0 siblings, 1 reply; 4+ messages in thread
From: Akira Yokosawa @ 2019-10-27 2:45 UTC (permalink / raw)
To: Nan Xiao; +Cc: perfbook, Paul E. McKenney
(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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about volatile usage
2019-10-27 2:45 ` Akira Yokosawa
@ 2019-10-27 17:11 ` Paul E. McKenney
2019-10-28 2:47 ` Nan Xiao
0 siblings, 1 reply; 4+ messages in thread
From: Paul E. McKenney @ 2019-10-27 17:11 UTC (permalink / raw)
To: Akira Yokosawa; +Cc: Nan Xiao, perfbook
On Sun, Oct 27, 2019 at 11:45:07AM +0900, Akira Yokosawa wrote:
> (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).
All good points!
And one reason that volatile survives is that it absolutely must have
certain properties in order for device drivers to work, and none of our
modern computing infrastructure will work without device drivers.
Thanx, Paul
> Thanks, Akira
>
> >
> > Thanks very much in advance!
> >
> > Best Regards
> > Nan Xiao
> >
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about volatile usage
2019-10-27 17:11 ` Paul E. McKenney
@ 2019-10-28 2:47 ` Nan Xiao
0 siblings, 0 replies; 4+ messages in thread
From: Nan Xiao @ 2019-10-28 2:47 UTC (permalink / raw)
To: paulmck; +Cc: Akira Yokosawa, perfbook
Hi Akira & Paul,
Thanks very much for your time and explanation!
Best Regards
Nan Xiao
On Mon, Oct 28, 2019 at 1:11 AM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Sun, Oct 27, 2019 at 11:45:07AM +0900, Akira Yokosawa wrote:
> > (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).
>
> All good points!
>
> And one reason that volatile survives is that it absolutely must have
> certain properties in order for device drivers to work, and none of our
> modern computing infrastructure will work without device drivers.
>
> Thanx, Paul
>
> > Thanks, Akira
> >
> > >
> > > Thanks very much in advance!
> > >
> > > Best Regards
> > > Nan Xiao
> > >
> >
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-10-28 2:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-25 13:32 Question about volatile usage Nan Xiao
2019-10-27 2:45 ` Akira Yokosawa
2019-10-27 17:11 ` Paul E. McKenney
2019-10-28 2:47 ` Nan Xiao
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.