Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756889AbdLUDbL (ORCPT ); Wed, 20 Dec 2017 22:31:11 -0500 Received: from mail-pl0-f68.google.com ([209.85.160.68]:34056 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756192AbdLUDbE (ORCPT ); Wed, 20 Dec 2017 22:31:04 -0500 X-Google-Smtp-Source: ACJfBosDz5dTOwL9WgnHnd882vYRi4ZppBI3EjNB71AerI+brVHqkYn1xiCpgC+cUYSx6qyMuXph0Q== Date: Thu, 21 Dec 2017 09:00:55 +0530 From: afzal mohammed To: "Paul E. McKenney" Cc: Alan Stern , Peter Zijlstra , parri.andrea@gmail.com, will.deacon@arm.com, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, linux-kernel@vger.kernel.org, elena.reshetova@intel.com Subject: Re: Prototype patch for Linux-kernel memory model Message-ID: <20171221033055.GA3944@afzalpc> References: <20171114075925.apzztfksn4f4y5ue@hirez.programming.kicks-ass.net> <20171114171505.GS3624@linux.vnet.ibm.com> <20171115163749.GA8555@linux.vnet.ibm.com> <20171220113145.GA5082@afzalpc> <20171220164538.GL7829@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171220164538.GL7829@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1976 Lines: 57 Hi, On Wed, Dec 20, 2017 at 08:45:38AM -0800, Paul E. McKenney wrote: > On Wed, Dec 20, 2017 at 05:01:45PM +0530, afzal mohammed wrote: > > > +It is tempting to assume that CPU0()'s store to x is globally ordered > > > +before CPU1()'s store to z, but this is not the case: > > > + > > > + /* See Z6.0+pooncerelease+poacquirerelease+mbonceonce.litmus. */ > > > + void CPU0(void) > > > + { > > > + WRITE_ONCE(x, 1); > > > + smp_store_release(&y, 1); > > > + } > > > + > > > + void CPU1(void) > > > + { > > > + r1 = smp_load_acquire(y); > > > + smp_store_release(&z, 1); > > > + } > > > + > > > + void CPU2(void) > > > + { > > > + WRITE_ONCE(z, 2); > > > + smp_mb(); > > > + r2 = READ_ONCE(x); > > > + } > > > + > > > +One might hope that if the final value of r1 is 1 and the final value > > > +of z is 2, then the final value of r2 must also be 1, but the opposite > > > +outcome really is possible. > > > > As there are 3 variables to have the values, perhaps, it might be > > clearer to have instead of "the opposite.." - "the final value need > > not be 1" or was that a read between the lines left as an exercise to > > the idiots ;) > > Heh! Good catch, thank you! How about the following for the paragraph > immediately after that litmus test? > > One might hope that if the final value of r0 is 1 and the final > value of z is 2, then the final value of r1 must also be 1, > but it really is possible for r1 to have the final value of 0. > The reason, of course, is that in this version, CPU2() is not > part of the release-acquire chain. This situation is accounted > for in the rules of thumb below. > > I also fixed r1 and r2 to match the names in the actual litmus test. Since it is now mentioned that r1 can have final value of 0, though it is understood, it might make things crystal clear and for the sake of completeness to also show the non-automatic variable x being initialized to 0. Thanks for taking into account my opinion. afzal