Re: [PATCH memory-model] docs: memory-barriers: Add note on compiler transformation and address deps

[Paul E. McKenney]

On Sat, Oct 21, 2023 at 03:36:21PM +0200, Jonas Oberhauser wrote:
> 
> Am 10/20/2023 um 8:13 PM schrieb Paul E. McKenney:
> > On Fri, Oct 20, 2023 at 06:00:19PM +0200, Jonas Oberhauser wrote:
> > > Am 10/20/2023 um 3:57 PM schrieb Paul E. McKenney:
> > > > On Fri, Oct 20, 2023 at 11:29:24AM +0200, Jonas Oberhauser wrote:
> > > > > Am 10/19/2023 um 6:39 PM schrieb Paul E. McKenney:
> > > > > > On Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
> > > > > > > Hi Paul,
> > > > > > > [...]
> > > > > > The compiler is forbidden from inventing pointer comparisons.
> > > > > TIL :) Btw, do you remember a discussion where this is clarified? A quick
> > > > > search didn't turn up anything.
> > > > This was a verbal discussion with Richard Smith at the 2020 C++ Standards
> > > > Committee meeting in Prague.  I honestly do not know what standardese
> > > > supports this.
> > > Richard Smith
> > > Then this e-mail thread shall be my evidence for future discussion.
> > I am sure that Richard will be delighted, especially given that he
> > did not seem at all happy with this don't-invent-pointer-comparisons
> > rule.  ;-)
> 
> Neither am I :D

Why do you want to invent pointer comparisons?

>From a practical standpoint, one big problem with them is that they
make it quite hard to write certain types of software, including device
drivers, memory allocators, things like memset(), and so on.

> He can voice his delightenment or lack thereof to me if we ever happen to
> meet in person.

More likely to me, but I will happily pass it on.

> > > I think this tiny rewrite makes it much more clear. Specifically it tells *why* the text is historical (and why we maybe don't need to read it anymore).
> > Good point!  I reworked this a bit and added it to both HISTORICAL
> > sections, with your Suggested-by.
> 
> The new version looks good to me!
> 
> > > > > > The longer-term direction, perhaps a few years from now, is for the
> > > > > > first section to simply reference rcu_dereference.rst and for the second
> > > > > > section to be removed completely.
> > > > > Sounds good to me, but that doesn't mean we need to compromise the
> > > > > readability in the interim :)
> > > > Some compromise is needed for people that read the document some time
> > > > back and are looking for something specific.
> > > Yes. But the compromise should be "there's a blob of text other people don't
> > > need to read", not "there's a blob of text that will leave other people
> > > confused".
> > Fair enough in general, but I cannot promise to never confuse people.
> > This is after all memory ordering.  And different people will be confused
> > by different things.
> 
> You can say that twice. In fact I suspect this is not the first time you say
> that :))

Easy for me to say, "that that that that that that that that that that"!

							Thanx, Paul