From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Mar 30 00:12:47 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 EEADE356DC2; Sat, 30 Mar 2013 00:12:46 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by www.open-std.org (Postfix) with ESMTP id 4D741356DA6 for ; Sat, 30 Mar 2013 00:12:45 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54930) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1ULiTR-0000Hr-rX (Exim 4.72) (return-path ); Fri, 29 Mar 2013 23:12:41 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1ULiTR-0003Xj-HV (Exim 4.72) (return-path ); Fri, 29 Mar 2013 23:12:41 +0000 Received: from [87.112.179.244] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 29 Mar 2013 23:12:41 +0000 Date: 29 Mar 2013 23:12:41 +0000 From: "N.M. Maclaren" To: "Bader, Reinhold" Cc: "Van.Snyder@jpl.nasa.gov" , fortran standards email list for J3 , sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4944) AW: (j3.2006) Thoughts on Reinhold's thoughts Message-ID: In-Reply-To: <20130329212446.AD585356D97@www.open-std.org> References: <20130329203623.0D66F356D96@www.open-std.org> <20130329212446.AD585356D97@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk 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 inconsistencies > that might result, implementors will start a head-hunt ... > > For this reason I'd like to see *concrete examples* that show how things > can go badly wrong if the synchronization requirements are relaxed. 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. 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 :-( 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. 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. Regards, Nick Maclaren.