From: Andrea Parri <parri.andrea@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kenneth-Lee-2012@foxmail.com, linux-kernel@vger.kernel.org,
paulmck@kernel.org
Subject: Re: Question about PB rule of LKMM
Date: Thu, 7 Mar 2024 22:06:08 +0100 [thread overview]
Message-ID: <ZeosQDNK8hN/KgJR@andrea> (raw)
In-Reply-To: <b3137a9b-0776-421f-8b3b-b5ddd6bce96a@rowland.harvard.edu>
> > C test
> >
> > {}
> >
> > P0(int *x)
> > {
> > *x = 1;
> > }
> >
> > P1(int *x)
> > {
> > *x = 2;
> > }
>
> Ah, but you see, any time you run this program one of those statements
> will execute before the other. Which will go first is indeterminate,
> but the chance of them executing at _exactly_ the same moment is zero.
TBH, I don't. But I trust you know your memory controller. ;-)
> > This appears to be the key observation. For if, in the operational model,
> > (not F ->xb E) implies (E ->xb F) then I'll apologize for the noise. :-)
>
> Okay, so it looks like we're in violent agreement. :-)
Fiuu!! ;-)
> The way you put it also relies on argument by contradiction. This
> just wasn't visible, because you omitted a lot of intermediate steps in
> the reasoning.
>
> If you want to see this in detail, try explaining why it is that "W is
> coherence-later than E" implies "E must execute before W propagates to
> E's CPU" in the operational model.
But that's all over in explanation.txt?? FWIW, a quick search returned
(wrt fre):
R ->fre W means that W overwrites the value which R reads, but it
doesn't mean that W has to execute after R. All that's necessary
is for the memory subsystem not to propagate W to R's CPU until
after R has executed
I really don't see how the operational model could explain even a simple
MP without "knowing" this fact.
IAC, I'm pretty sure my "intermediate steps" wouldn't be using the same
forcing condition. :-)
Andrea
next prev parent reply other threads:[~2024-03-07 21:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 3:18 Question about PB rule of LKMM Kenneth-Lee-2012
2024-03-05 18:00 ` Andrea Parri
2024-03-06 9:53 ` Kenneth-Lee-2012
2024-03-06 17:36 ` Andrea Parri
2024-03-06 18:29 ` Alan Stern
2024-03-06 19:24 ` Andrea Parri
2024-03-07 0:45 ` Kenneth-Lee-2012
2024-03-07 15:52 ` Andrea Parri
2024-03-07 17:25 ` Alan Stern
2024-03-07 18:18 ` Andrea Parri
2024-03-07 18:30 ` Alan Stern
2024-03-07 19:08 ` Andrea Parri
2024-03-07 19:46 ` Alan Stern
2024-03-07 21:06 ` Andrea Parri [this message]
2024-03-08 17:54 ` Alan Stern
2024-03-08 21:29 ` Andrea Parri
2024-03-08 3:10 ` Kenneth-Lee-2012
2024-03-08 21:38 ` Andrea Parri
2024-03-09 5:43 ` Kenneth-Lee-2012
2024-03-10 2:27 ` Andrea Parri
2024-03-10 2:52 ` Kenneth-Lee-2012
2024-03-11 3:41 ` Kenneth-Lee-2012
[not found] ` <20240311034104.7iffcia4k5rxvgog@kllt01>
2024-03-11 8:20 ` Kenneth-Lee-2012
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZeosQDNK8hN/KgJR@andrea \
--to=parri.andrea@gmail.com \
--cc=Kenneth-Lee-2012@foxmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox