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.
Best wishes,
jonas
Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
Hi Paul,
The "more up-to-date information" makes it sound like (some of) the
information in this section is out-of-date/no longer valid.
The old smp_read_barrier_depends() that these section cover really
does no longer exist.
You mean that they *intend to* cover? smp_read_barrier_depends never
appears in the text, so anyone reading this section without prior
knowledge has no way of realizing that this is what the sections are
talking about.
On the other hand the implicit address dependency barriers that do exist
are mentioned in the text. And that part is still true.
But after reading the sections, it seems the information is valid, but
discusses mostly the history of address dependency barriers.
Given that the sepcond part specifically already starts with a
disclaimer that this information is purely relevant to people interested
in history or working on alpha, I think it would make more sense to
modify things slightly differently.
Firstly I'd remove the "historical" part in the first section, and add
two short paragraphs explaining that
- every marked access implies a address dependency barrier
This is covered in rcu_dereference.rst.
Let me quote a much wiser man than myself here: "
The problem is that people insist on diving into the middle of documents,
so sometimes repetition is a necessary form of self defense. ;-)
"
The main reason I would like to add this here at the very top is that
- this section serves to frigthen children about the dangers of address
dependencies,
- never mentions a way to add them - I need to happen to read another
section of the manual to find that out
- and says this information is historical without specifying which parts
are still relevant
(and the parts that are still there are all still relevant, while the
parts that only the authors know was intended to be there and is
out-of-date is already gone).
So I would add a disclaimer specifying that (since 4.15) *all* marked
accesses imply read dependency barriers which resolve most of the issues
mentioned in the remainder of the article.
However, some issues remain because the dependencies that are preserved
by such barriers are just *semantic* dependencies, and readers should
check rcu_dereference.rst for examples of what that implies.
[...]
most situations would be better served by an _acquire() suffix than by
a relaxed version of [...] an atomic [...]
I completely agree. I even considered removing address dependencies
altogether from the company-internal memory models.
But people sometimes get a little bit angry and start asking many questions.
The valuable time of the model maintainer should be considered when
designing memory models.
- address dependencies considered by the model are *semantic*
dependencies, meaning that a *syntactic* dependency is not sufficient to
imply ordering; see the rcu file for some examples where compilers can
elide syntactic dependencies
There is a bunch of text in rcu_dereference.rst to this effect. Or
is there some aspect that is missing from that document?
That's what I meant by "see the rcu file" --- include a link to
rcu_dereference.rst in that paragraph.
So that people know to check out rcu_dereference.rst for more
explanations to this effect.
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 :)
[...]
The problem is that people insist on diving into the middle of documents,
so sometimes repetition is a necessary form of self defense. ;-)
But I very much appreciate your review and feedback, and I also apologize
for my slowness.
Thanx, Paul
Thanks for the response, I started thinking my mails aren't getting
through again.
Have fun,
jonas
