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: Thu, 7 Mar 2024 13:30:22 -0500	[thread overview]
Message-ID: <bde188b0-1c5b-4b3b-94de-395a52fc37ce@rowland.harvard.edu> (raw)
In-Reply-To: <ZeoFBkB1BeTdEQsn@andrea>

On Thu, Mar 07, 2024 at 07:18:46PM +0100, Andrea Parri wrote:
> > So I guess you're talking about the second, intuitive meaning.  That's 
> > very simple to explain.  Since every instruction executes at _some_ 
> > time, and since we can safely assume that no two instructions execute at 
> > exactly the _same_ time, if F doesn't execute before E then E must 
> > execute before F.  Or using your terms, (not F ->xb E) implies (E ->xb 
> > F).  Would that answer the original question satisfactorily?
> 
> I'd disagree with these premises: certain instructions can and do execute
> at the same time.

Can you give an example?

>  FWIW, in the formal model, it is not that difficult to
> provide examples of "(not F ->xb E) and (not E ->xb F)".

That's because the xb relation in the formal model does not fully 
capture our intuitive notion of "executes at the same time" in the 
informal operational model.

Also, it's important to distinguish between:

(1)	Two instructions that are forced (say by a dependency) or known 
	(say by an rfe link) to execute in a particular order; versus

(2)	Two instructions that may execute in either order but do execute
	in some particular order during a given run of the program.

The formal xb relation corresponds more to (1), whereas the informal 
notion corresponds more to (2).

> > The new text says the same thing as the original, just in a more 
> > condensed way.  It skips the detailed explanation of why E must execute 
> > before W propagates to E's CPU, merely saying that it is because "W is 
> > coherence-later than E".  I'm not sure this is an improvement; the 
> > reader might want to know exactly how this reasoning goes.
> 
> The current text relies on an argument by contradiction.  A contradiction
> is reached by "forcing" (F ->xb E), hence all it can be concluded is that
> (not F ->xb E).  Again, AFAICS, this doesn't match the claim in the text.

That's why I suggested adding an extra sentence to the paragraph (which 
you did not quote in your reply).  That sentence gave a direct argument.

Alan

  reply	other threads:[~2024-03-07 18:30 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 [this message]
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
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=bde188b0-1c5b-4b3b-94de-395a52fc37ce@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).