From owner-sc22wg5@open-std.org Thu Nov 6 19:44:03 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 6EBCFCA5FE8; Thu, 6 Nov 2008 19:44:03 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1260 seconds by postgrey-1.18 at www2.open-std.org; Thu, 06 Nov 2008 19:44:02 CET Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by www2.open-std.org (Postfix) with ESMTP id 7038ACA343A for ; Thu, 6 Nov 2008 19:44:01 +0100 (CET) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA6IMvbY026261 for ; Thu, 6 Nov 2008 18:22:59 GMT Received: from ranma.sfbay.sun.com (ranma.SFBay.Sun.COM [129.146.84.89]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA6IMvca049464 for ; Thu, 6 Nov 2008 10:22:57 -0800 (PST) Received: (from michaeli@localhost) by ranma.sfbay.sun.com (8.11.7p1+Sun/8.11.7) id mA6IMv410750 for sc22wg5@open-std.org; Thu, 6 Nov 2008 10:22:57 -0800 (PST) Date: Thu, 6 Nov 2008 10:22:57 -0800 (PST) From: Michael Ingrassia Message-Id: <200811061822.mA6IMv410750@ranma.sfbay.sun.com> To: sc22wg5@open-std.org Subject: Re: (j3.2006) (SC22WG5.3631) [ukfortran] N1751 X-Sun-Charset: US-ASCII Sender: owner-sc22wg5@open-std.org Precedence: bulk >Can you point me at anything in the standard that states that principle? 2.4.2p1 says that Execution of a program consists of the asynchronous execution of a fixed number of images. Chapter 8 describes the control flow within an image. Failure to execute image P is a failure to execute the program. Progress in image P can be paused at PAUSE statements or at image control statements, but as you say I think that failure to advance otherwise might be considered "gratuitously perverse". >More seriously, why do you think that the processor can (let alone should) >decide that the best strategy is to stop doing what it thinks is useful >work in order to achieve fairness between images? Knowing when to do that >and when not to is equivalent to solving the Halting Problem .... Yes, anyone can write non-halting programs and a processor can't weed them out a priori. That doesn't mean that users must always despair; by use of discipline they can write programs which they can prove will in fact halt. I've seen lots of such proofs. The question is whether the (implied) proof that this program in NOTE 8.38 halts can be supplied based on our standard or whether it requires extra assumptions. I think we have to assume that the system scheduler respects the Fortran concept of image control statements. My claim is that a scheduler consistent with the execution rules in the standard can't permanently swap out an image which is not suspended at an image control statement. Or so I thought. Maybe that means existing thread schedulers would need to learn a wee bit of Fortran to become image schedulers ? >>What am I missing? >Any wording in the standard that I, as the local expert, could use to beat >the vendor over the head with :-( Ah. --Michael I. BTW your mail headers included >To: sc22wg5@open-std.org >Reply-to: fortran standards email list for J3 which seems odd to me. I don't understand why replies aren't directed to sc22wg5.