All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akira Yokosawa <akiyks@gmail.com>
To: paulmck@kernel.org
Cc: Motohiro Kanda <kanda.motohiro@gmail.com>, perfbook@vger.kernel.org
Subject: Re: [PATCH -perfbook] whymb: Fix description of compiler mischief
Date: Fri, 4 Dec 2020 07:42:29 +0900	[thread overview]
Message-ID: <4b773dda-d083-702a-9519-f8fc76eadac1@gmail.com> (raw)
In-Reply-To: <20201203165143.GX1437@paulmck-ThinkPad-P72>

On Thu, 3 Dec 2020 08:51:43 -0800, Paul E. McKenney wrote:
> On Wed, Dec 02, 2020 at 11:50:27PM +0900, Akira Yokosawa wrote:
>> >From 89ab8426f9821b6a8bf86e9d4f7eb596e0cfed73 Mon Sep 17 00:00:00 2001
>> From: Akira Yokosawa <akiyks@gmail.com>
>> Date: Wed, 2 Dec 2020 07:35:08 +0900
>> Subject: [PATCH -perfbook] whymb: Fix description of compiler mischief
>>
>> In this code snippet, the assertion can not fire due to different
>> reasons.
>> When bar() observes b == 1, the smp_mb() assures a == 1.
>> When bar() observes b == 0, the while loop will loop forever and
>> the assertion can't be reached.
>>
>> This was pointed out by Motohiro Kanda in his Japanese translation
>> of perfbook [1].
>>
>> [1]: https://sites.google.com/site/kandamotohiro/perfbook-d/perfbookappendixf10
>>
>> Cc: Motohiro Kanda <kanda.motohiro@gmail.com>
>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> 
> I took this patch as is, but added a patch on top that (hopefully)
> does a better job of explaining the situation.  Thank you both!!!

Ah, this was your original intention of this Quick Quiz.

Yes, this explains the situation much better.

I did thought about dropping the smp_mb() in the snippet at first,
but that would require me to do a larger rewrite of the answer.
Instead, I submitted the minimal patch to attract your attention. ;-)

> 
> Would it also help to add a reference to the discussion of control
> dependencies? 

Yes, I think so.
Section 15.3.3 or Section 15.3 as a whole would be a good reference.

        Thanks, Akira


>                The straightforward answer given that information is
> "control dependencies do not order later loads".
> 
> Motohiro, would you be OK with my mentioning your translation in the
> next set of release notes for perfbook?  Either way, I much appreciate
> your doing this work!
> 
> 							Thanx, Paul
> 

  reply	other threads:[~2020-12-03 22:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-02 14:50 [PATCH -perfbook] whymb: Fix description of compiler mischief Akira Yokosawa
2020-12-03 11:04 ` Motohiro Kanda
2020-12-03 13:38   ` Akira Yokosawa
2020-12-03 16:51 ` Paul E. McKenney
2020-12-03 22:42   ` Akira Yokosawa [this message]
2020-12-05  3:16   ` Motohiro Kanda
2020-12-08 18:43     ` Paul E. McKenney
2020-12-09  6:17       ` Motohiro Kanda
2020-12-10  1:29         ` Paul E. McKenney
2020-12-10  1:32           ` Motohiro Kanda

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=4b773dda-d083-702a-9519-f8fc76eadac1@gmail.com \
    --to=akiyks@gmail.com \
    --cc=kanda.motohiro@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=perfbook@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.