Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753348AbaBSJqt (ORCPT ); Wed, 19 Feb 2014 04:46:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60975 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752954AbaBSJqq (ORCPT ); Wed, 19 Feb 2014 04:46:46 -0500 Subject: Re: [RFC][PATCH 0/5] arch: atomic rework From: Torvald Riegel To: Peter.Sewell@cl.cam.ac.uk Cc: "mark.batty@cl.cam.ac.uk" , Paul McKenney , Peter Zijlstra , Linus Torvalds , Will Deacon , "ramana.radhakrishnan" , David Howells , "linux-arch@vger.kernel.org" , Linux Kernel Mailing List , Andrew Morton , Ingo Molnar , "gcc@gcc.gnu.org" In-Reply-To: References: <1392756211.18779.8263.camel@triegel.csb> Content-Type: text/plain; charset="UTF-8" Date: Wed, 19 Feb 2014 10:46:04 +0100 Message-ID: <1392803164.18779.8498.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2014-02-18 at 23:48 +0000, Peter Sewell wrote: > On 18 February 2014 20:43, Torvald Riegel wrote: > > On Tue, 2014-02-18 at 12:12 +0000, Peter Sewell wrote: > >> Several of you have said that the standard and compiler should not > >> permit speculative writes of atomics, or (effectively) that the > >> compiler should preserve dependencies. In simple examples it's easy > >> to see what that means, but in general it's not so clear what the > >> language should guarantee, because dependencies may go via non-atomic > >> code in other compilation units, and we have to consider the extent to > >> which it's desirable to limit optimisation there. > > > > [...] > > > >> 2) otherwise, the language definition should prohibit it but the > >> compiler would have to preserve dependencies even in compilation > >> units that have no mention of atomics. It's unclear what the > >> (runtime and compiler development) cost of that would be in > >> practice - perhaps Torvald could comment? > > > > If I'm reading the standard correctly, it requires that data > > dependencies are preserved through loads and stores, including nonatomic > > ones. That sounds convenient because it allows programmers to use > > temporary storage. > > The standard only needs this for consume chains, That's right, and the runtime cost / implementation problems of mo_consume was what I was making statements about. Sorry if that wasn't clear. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/