Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751643AbaBRUre (ORCPT ); Tue, 18 Feb 2014 15:47:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60741 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911AbaBRUrd (ORCPT ); Tue, 18 Feb 2014 15:47:33 -0500 Subject: Re: [RFC][PATCH 0/5] arch: atomic rework From: Torvald Riegel To: Peter.Sewell@cl.cam.ac.uk Cc: Linus Torvalds , "mark.batty@cl.cam.ac.uk" , Paul McKenney , Peter Zijlstra , 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: Content-Type: text/plain; charset="UTF-8" Date: Tue, 18 Feb 2014 21:46:24 +0100 Message-ID: <1392756384.18779.8272.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 18:21 +0000, Peter Sewell wrote: > On 18 February 2014 17:38, Linus Torvalds wrote: > > On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell wrote: > >> > >> For example, suppose we have, in one compilation unit: > >> > >> void f(int ra, int*rb) { > >> if (ra==42) > >> *rb=42; > >> else > >> *rb=42; > >> } > > > > So this is a great example, and in general I really like your page at: > > > >> For more context, this example is taken from a summary of the thin-air > >> problem by Mark Batty and myself, > >> , and the problem with > >> dependencies via other compilation units was AFAIK first pointed out > >> by Hans Boehm. > > > > and the reason I like your page is that it really talks about the > > problem by pointing to the "unoptimized" code, and what hardware would > > do. > > Thanks. It's certainly necessary to separately understand what compiler > optimisation and the hardware might do, to get anywhere here. But... > > > As mentioned, I think that's actually the *correct* way to think about > > the problem space, because it allows the programmer to take hardware > > characteristics into account, without having to try to "describe" them > > at a source level. > > ...to be clear, I am ultimately after a decent source-level description of what > programmers can depend on, and we (Mark and I) view that page as > identifying constraints on what that description can say. There are too > many compiler optimisations for people to reason directly in terms of > the set of all transformations that they do, so we need some more > concise and comprehensible envelope identifying what is allowed, > as an interface between compiler writers and users. AIUI that's basically > what Torvald is arguing. Yes, that's one reason. Another one is that if a programmer would actually want to use atomics in a machine-independent / portable way, he/she does also not want to reason about how all those transformations might interact with the machine's memory model. -- 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/