linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Andrea Parri <parri.andrea@gmail.com>
Cc: Kenneth-Lee-2012@foxmail.com, linux-kernel@vger.kernel.org,
	paulmck@kernel.org
Subject: Re: Question about PB rule of LKMM
Date: Fri, 8 Mar 2024 12:54:42 -0500	[thread overview]
Message-ID: <198f16f6-1d61-4868-b522-1bc5d34bf7af@rowland.harvard.edu> (raw)
In-Reply-To: <ZeosQDNK8hN/KgJR@andrea>

On Thu, Mar 07, 2024 at 10:06:08PM +0100, Andrea Parri wrote:
> > > 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.  ;-)

I can't tell which aspect of this bothers you more: the fact that the 
text uses an argument by contradiction, or the fact that it ignores the 
possibility of two instructions executing at the same time.

If it's the latter, consider this: Although the text doesn't say so, 
the reasoning it gives also covers the case where F executes at the same 
time as E.  You can still deduce that W must have propagated to E's 
CPU before E executed, because W must propagate to every CPU before F 
executes.

> > 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

(In fact, that sentence isn't entirely accurate.  It should say "... not 
to propagate W (or a co-later store)...".)

Let's consider coe instead of fre.  The description of how the 
operational model manages the coherence order of stores is found in 
section 13 (AN OPERATIONAL MODEL):

	When CPU C executes a store instruction, it tells the memory 
	subsystem to store a certain value at a certain location.  The 
	memory subsystem propagates the store to all the other CPUs as 
	well as to RAM.  (As a special case, we say that the store 
	propagates to its own CPU at the time it is executed.)  The 
	memory subsystem also determines where the store falls in the 
	location's coherence order.  In particular, it must arrange for 
	the store to be co-later than (i.e., to overwrite) any other 
	store to the same location which has already propagated to CPU 
	C.

So now if E is a store and is co-before W, how do we know that W didn't 
propagate to E's CPU before E executed?  It's clear from the last 
sentence of the text above: If W had propagated to E's CPU before E 
executed then the memory subsystem would have arranged for E to be 
co-later than W.  That's an argument by contradiction, and there's no 
way to avoid it here.

Alan

  reply	other threads:[~2024-03-08 17:54 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
2024-03-08 17:54                         ` Alan Stern [this message]
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=198f16f6-1d61-4868-b522-1bc5d34bf7af@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=Kenneth-Lee-2012@foxmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=parri.andrea@gmail.com \
    --cc=paulmck@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).