From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Mar 30 10:48:50 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 2EC32356DC4; Sat, 30 Mar 2013 10:48:49 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from postout.lrz.de (postout.lrz.de [129.187.254.115]) by www.open-std.org (Postfix) with ESMTP id 0E815356DC3 for ; Sat, 30 Mar 2013 10:48:48 +0100 (CET) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout4.mail.lrz.de (Postfix) with ESMTP id 1C303200BC; Sat, 30 Mar 2013 10:48:48 +0100 (CET) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de Received: from postout4.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id 4SV6yhSHlgFv; Sat, 30 Mar 2013 10:48:47 +0100 (CET) Received: from BADWLRZ-SWHBT2.ads.mwn.de (BADWLRZ-SWHBT2.ads.mwn.de [IPv6:2001:4ca0:0:108::126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "BADWLRZ-SWHBT2", Issuer "BADWLRZ-SWHBT2" (not verified)) by postout4.mail.lrz.de (Postfix) with ESMTPS id 39D10200B8; Sat, 30 Mar 2013 10:48:47 +0100 (CET) Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::6de5:ff8b:1900:b1a1]) by BADWLRZ-SWHBT2.ads.mwn.de ([fe80::5951:9dc3:7b2b:14ba%13]) with mapi id 14.01.0438.000; Sat, 30 Mar 2013 10:48:46 +0100 From: "Bader, Reinhold" To: "N.M. Maclaren" CC: "Van.Snyder@jpl.nasa.gov" , fortran standards email list for J3 , sc22wg5 Subject: AW: (SC22WG5.4945) [ukfortran] AW: (j3.2006) Thoughts on Reinhold's thoughts Thread-Topic: (SC22WG5.4945) [ukfortran] AW: (j3.2006) Thoughts on Reinhold's thoughts Thread-Index: AQHOLNL0O1105gqsTEi9ICRJBMj3/Ji9+VgQ Date: Sat, 30 Mar 2013 09:48:46 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B59F2B4D0@BADWLRZ-SWMBX11.ads.mwn.de> References: <20130329203623.0D66F356D96@www.open-std.org> <20130329212446.AD585356D97@www.open-std.org> <20130329231248.0A33D356DA7@www.open-std.org> In-Reply-To: <20130329231248.0A33D356DA7@www.open-std.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.187.48.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk Hello Nick,=20 > -----Urspr=FCngliche Nachricht----- > Von: owner-sc22wg5@open-std.org [mailto:owner-sc22wg5@open-std.org] Im > Auftrag von N.M. Maclaren > Gesendet: Samstag, 30. M=E4rz 2013 00:13 > An: Bader, Reinhold > Cc: Van.Snyder@jpl.nasa.gov; fortran standards email list for J3; sc22wg5 > Betreff: (SC22WG5.4945) [ukfortran] AW: (j3.2006) Thoughts on Reinhold's > thoughts >=20 > On Mar 29 2013, Bader, Reinhold wrote: > > > > Agreed. With respect to the big barrier in CHANGE TEAM let me note that > > there are risks to any path we take: > > > > * if it is retained and no other way is found to *efficiently* exchange > > data between teams, the teams feature will be regarded as a half-baked > > solution by programmers > > > > * if it is removed and we fail to nail down the possible inconsistencie= s > > that might result, implementors will start a head-hunt ... > > > > For this reason I'd like to see *concrete examples* that show how thing= s > > can go badly wrong if the synchronization requirements are relaxed. >=20 > I am afraid that is a serious mistake. Virtually every design that has > removed 'unnecessary' restrictions without a mathematical proof that it > is safe to do so has introduced inconsistencies. For example, UPC has > defined behaviour that cannot practically be implemented - I was certain > that it would deadlock when reading the specification, and I was right. > That's in one of my old WG5 or J3 documents. I.e. I think that the risks > of the second path are vastly higher than those of the first one. >=20 > The problem about PGAS is that it is effectively a virtual shared memory > model, and so has almost all of the problems of shared-memory models. > Van's point is the key. Unless we can prove (rigorously) that the model > is correct, we should assume that it is incorrect, and will usually be > right :-( I understand your concerns (and admit that I am also out of my depth where the semantics of advanced memory models are concerned), but would like to m= ake the following comments: (1) The memory model papers you reference use a concept of computation that= does not include synchronization operations. The discussion for Fortran th= erefore needs=20 to focus on two different levels: The first one concerning operations= that permit=20 memory updates in unordered segments (atomics, events) - that's where the memory model is needed - , and the second one that should = be allowed=20 to argue on the basis of *existing* synchronization semantics (teams!= ).=20 (2) The concrete examples I'd like to see of course do not constitute mathe= matical=20 proof. But they would provide valuable heuristics simple on whether o= r not to=20 continue considering the second alternative.=20 >=20 > This is my point about desperately needing a defined memory model that > we can prove is consistent. POSIX and OpenMP don't have one, and are > hopelessly broken as a result. C++ does, and it's diabolically > complicated. I am getting somewhere with tracking down the relevant > theory, and think that we can do something, but adding ANY complications > to the basic segment model will probably break the approach I am looking > at, and I don't know of another. >=20 > If anyone would like pointers to the relevant papers, please ask. Be > warned: the easiest of them are hard going, and some of them dive into > HOL notation. But they contain examples of truly horrible behaviour > that really does get observed in practice - I have seen a certain amount > of it, myself. >=20 >=20 > Regards, > Nick Maclaren. >=20