On Tue, 2014-02-18 at 18:21 +0000, Peter Sewell wrote: > On 18 February 2014 17:38, Linus Torvalds <torva...@linux-foundation.org> > wrote: > > On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell <peter.sew...@cl.cam.ac.uk> > > 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, > >> <www.cl.cam.ac.uk/~pes20/cpp/notes42.html>, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/