(j3.2006) (SC22WG5.3634) [ukfortran] N1751

Michael Ingrassia michaeli
Thu Nov 6 13:22:57 EST 2008


>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 at open-std.org
>Reply-to: fortran standards email list for J3 <j3 at j3-fortran.org>

which seems odd to me.  I don't understand why replies aren't directed
to sc22wg5.




More information about the J3 mailing list