From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Mar 30 12:31:12 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 3F59B356DD7; Sat, 30 Mar 2013 12:31:11 +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 88CCB356DD3 for ; Sat, 30 Mar 2013 12:31:09 +0100 (CET) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout3.mail.lrz.de (Postfix) with ESMTP id 24D3C201EC; Sat, 30 Mar 2013 12:31:09 +0100 (CET) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de Received: from postout3.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id Ss-fmkn2ksDu; Sat, 30 Mar 2013 12:31:08 +0100 (CET) Received: from BADWLRZ-SWHBT1.ads.mwn.de (BADWLRZ-SWHBT1.ads.mwn.de [IPv6:2001:4ca0:0:108::125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "BADWLRZ-SWHBT1", Issuer "BADWLRZ-SWHBT1" (not verified)) by postout3.mail.lrz.de (Postfix) with ESMTPS id 2C7D4201E5; Sat, 30 Mar 2013 12:31:08 +0100 (CET) Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::6de5:ff8b:1900:b1a1]) by BADWLRZ-SWHBT1.ads.mwn.de ([fe80::e42f:e9f5:bde9:f99b%16]) with mapi id 14.01.0438.000; Sat, 30 Mar 2013 12:31:07 +0100 From: "Bader, Reinhold" To: "N.M. Maclaren" CC: "Van.Snyder@jpl.nasa.gov" , fortran standards email list for J3 , sc22wg5 Subject: AW: AW: (SC22WG5.4945) [ukfortran] AW: (j3.2006) Thoughts on Reinhold's thoughts Thread-Topic: AW: (SC22WG5.4945) [ukfortran] AW: (j3.2006) Thoughts on Reinhold's thoughts Thread-Index: AQHOLNL0O1105gqsTEi9ICRJBMj3/Ji9+VgQgAAD54CAABfg8A== Date: Sat, 30 Mar 2013 11:31:06 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B59F2B546@BADWLRZ-SWMBX11.ads.mwn.de> References: <20130329203623.0D66F356D96@www.open-std.org> <20130329212446.AD585356D97@www.open-std.org> <20130329231248.0A33D356DA7@www.open-std.org> <166ED263DF83324D9A3BA67FB6772B2B59F2B4D0@BADWLRZ-SWMBX11.ads.mwn.de> In-Reply-To: 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 > -----Urspr=FCngliche Nachricht----- > Von: N.M. Maclaren [mailto:nmm1@hermes.cam.ac.uk] Im Auftrag von N.M. > Maclaren > Gesendet: Samstag, 30. M=E4rz 2013 11:47 > An: Bader, Reinhold > Cc: Van.Snyder@jpl.nasa.gov; fortran standards email list for J3; sc22wg5 > Betreff: Re: AW: (SC22WG5.4945) [ukfortran] AW: (j3.2006) Thoughts on > Reinhold's thoughts >=20 > On Mar 30 2013, Bader, Reinhold wrote: > > > > 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 make 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 > > therefore needs > > to focus on two different levels: The first one concerning > > operations that permit > > memory updates in unordered segments (atomics, events) - that's > > where the memory model is needed - , and the second one that shoul= d > > be allowed > > to argue on the basis of *existing* synchronization semantics > > (teams!). >=20 > Yes and no. They do have synchronisation operations, actually, but they > are semi-implicit. In C++, all accesses to atomic variables potentially > imply a fence, and the default ones include a release/acquire fence. > It's not a scalable model, and is almost unimplementable except on > cache coherent shared memory. >=20 > Also, the other aspect that makes me twitch is collectives. These > provide a communication channel that does not involve any form of > synchronisation. In that, they are very like atomics, but are not > restricted to atomic variables :-( >=20 > > (2) The concrete examples I'd like to see of course do not constitute > > mathematical > > proof. But they would provide valuable heuristics simple on whethe= r > > or not to > > continue considering the second alternative. >=20 > The trouble is that taking that approach has caused absolute chaos in > the past, because this area is SO fiendish. People have been completely > unable to produce examples that fail, programs have failed in real life, > that has been tracked down to an inconsistency in the standard, and it > has been then found to be unfixable :-( >=20 > Both POSIX threads and OpenMP have that, redoubled in spades, and it > has been 'resolved' in C and C++ only by incompatible changes to the > languages. Even so, C++ has one serious inconsistency that I know of > (which we blocked in Fortran), and C has dozens - even excluding the > old ones of incompatibilities in the serial specification. In older > languages, Modula 3 made a complete mess of this for the same reason, > and there were almost certainly many others. >=20 > If you can tell me a particular aspect that you are thinking of, I will > see if I can create an example. But, currently, the proposals are just > too inchoate (=3D just begun, with connotations of imperfect, undeveloped > and immature) to do much more. Nice term. I agree.=20 With respect to examples: I'd like to see whether an inconsistency with res= pect to the "regular" coarray memory model (i.e. excepting atomics and such - these wou= ld be dealt=20 with via "containment") can be produced if the synchronization requirements= on CHANGE TEAM are relaxed: * will all sequences of SYNC ALL, ALLOCATE and DEALLOCATE work properly? * will (with the added restrictions in section (F) of my comment file) all = allowed partial synchronization statements (SYNC IMAGES, EVENT POST/WAIT, LOCK/UNLOCK) work properly? Note that such cases of data races and synchronization deadlocks that are a= lready possible in F2008 coarrays are excluded - that's the tradeoff implicitly accepted by= the programming model. By "containment" I basically mean requirement T2 of N1930 (which itself may= leave some room for interpretation).=20 My suggestions generally are in direction of narrowing the semantics, excep= t for the CHANGE TEAM sync relaxation; while the narrowing is generally based on different reason= ing, your examples may well turn out to=20 demonstrate that the narrowing is required in order to avoid problems with = the sync relaxation. Note that since your suggestion also involves relaxation of the CHANGE TEAM= synchronization semantics,=20 you're under obligation of providing proof of correctness as well ... >=20 > Regards, > Nick.