From malcolm@nag.co.uk Thu Feb 6 15:03:44 1997 Received: from red.nag.co.uk ([192.156.217.2]) by dkuug.dk (8.6.12/8.6.12) with SMTP id PAA28340 for ; Thu, 6 Feb 1997 15:03:22 +0100 Received: from sedi8.nag.co.uk by red.nag.co.uk via SMTP (920330.SGI/920502.SGI) for sc22wg5@dkuug.dk id AA18479; Thu, 6 Feb 97 14:02:54 GMT Received: by sedi8.nag.co.uk (920330.SGI/920502.SGI) for @red.nag.co.uk:sc22wg5@dkuug.dk id AA15463; Thu, 6 Feb 97 14:02:52 GMT From: malcolm@nag.co.uk (Malcolm Cohen) Message-Id: <9702061402.AA15463@sedi8.nag.co.uk> Subject: Re: (SC22WG5.1303) Comment on 97-102 (ASYNC I/O) To: sc22wg5@dkuug.dk Date: Thu, 6 Feb 1997 14:02:49 +0000 (GMT) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3850 Michael Hennecke said: > > WG5/N1245 > > X3J3/97-102 > > page 9 of 16 > > > > | When a READ statement with the ASYNCHRONOUS > > | specifier is executed, the program shall not execute > > | any procedure call where any variable : > > | 1) in the input / output list or namelist, > [snip] > > | or subobject or parent object thereof, is passed as an > > | actual argument, until the corresponding wait operation > > | is executed, unless : > [snip] > > | 2) the corresponding dummy argument is an assumed > > | shape array > > | > > | Note: This restriction prevents interactions between > > | actual arguments passed with so-called > > | copyin/copyout semantics and asynchronous I/O. > > > > Question: Should we allow scalars? Can they be passed > > by copyin/out? Any other ways to force pass by address > > or descriptor? > > to my understanding, it is not sufficient for the dummy argument to > be an assumed shape array. At a CALL PROC(A(::2)) a dumb implementation > might still copy A(::2) to TMP(1:SIZE(A)/2), and put the address of > that TMP and TMP's length into an (ALLOCATABLE-like) descriptor, rather > than putting the address of A plus length and stride information into a > (POINTER-like) descriptor. Am I right? Yes and no. F90/F95 allows such a dumb implementation of assumed-shape arrays. 97-102 effectively disallows it for processors that do async i/o fully asynchronously. > I also think that the standard does not enforce pass by address for scalars, > so allowing them might lead (processor-depending) to strange effects. (97-102 does not allow scalars - this being an open question). We can certainly allow scalars to be passed if we make ASYNCHRONOUS (or not) one of the "characteristics" of a dummy argument, and requiring an explicit interface if any dummy argument has the ASYNCHRONOUS attribute. (Then the processor always knows what must be done). This might be overkill though. Anyway, copyin-copyout is fine for scalar arguments provided the copying is done by the called procedure not the caller - because the ASYNC attribute in the called procedure will tell the processor to refetch the dummy's value when needed after any procedure call. I do not know whether any existing implementations do caller-copying of such arguments, but I suspect not (and for module/internal procs with INTENT(IN) args, where such args are usually passed by value, the processor can see the ASYNC attribute and so NOT pass them by value). > How about allowing all this, and putting some requirement on the processor > to reject such code if it has a dumb implementation of assumed shape, No, just demand that the processor do it right. > passes scalars by value, Ditto - either we should make the processor get it right or leave it out. > or does other COPYIN/COPYOUT where the async I do not know what you have in mind - something other than scalar or array? > stuff cannot allow that? The program would then rely on a processor-dependent > feature, and the processor would be responsible to tell if it cannot > handle it as expected. No, it *must* be portable. If a processor does async i/o asynchronously (there is no problem if it does async i/o synchronously, or if does an implicit WAIT on a procedure call when a variable in an async i/o list might be externally visible, e.g. it is in a module or is a target) then (a) it must get it right, and (b) we must make it possible (and not too hard) to get it right. Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)