(j3.2006) synchronizing I/O

[John Reid]

malcolm at nag-j.co.jp wrote:
> 
>> The purpose of this is to allow simple diagnostic and error output to be 
>> permitted from any image. My own experience is that this is very useful while 
>> developing a program. I label each record with the index of the image that wrote 
>> it.
> 
> That's what I thought you had in mind, but the words don't achieve that.
> 
>> "For the preconnected output files identified by the values of the named
>> constants OUTPUT_UNIT and ERROR_UNIT of the intrinsic module ISO_FORTRAN_ENV, 
>> each record shall be written by a single image. The processor shall ensure that 
>> once an image commences transferring the data of a record to the file, no other 
>> image executes an input/output statement for the file until the whole record has 
>> been transferred."
> 
> Consider the program
> 
> PROGRAM problem
>   IF (THIS_IMAGE()==1) THEN
>     WRITE(*,'(A)',ADVANCE='NO') 'x'
>     SYNC IMAGES
>     SYNC IMAGES
>     WRITE(*,'(A)') '1'
>   ELSE IF (THIS_IMAGE()==2) THEN
>     SYNC IMAGES
>     WRITE(*,'(A)',ADVANCE='NO') 'y'
>     SYNC IMAGES
>     WRITE(*,'(A)') '2'
>   END IF
> END

I think this would deadlock if we accept my words. There are already plenty of 
ways to get deadlock, so I can accept this, but perhaps we should not be adding 
a new way.
> 
>>From your description of your intent I would guess that you want this to be a standard-conforming program, and that either it produces the output
>   x1
>   y2
> or the output
>   y2
>   x1
> but not the output
>   x2
>   y1
> or any other variation.

That would be nice and that would be the effect if the wording was less 
restrictive and each image had a buffered at the record level. Not sure how we 
could state that in standardese. Nor how easy it would be for implementers.

> The trouble is, the program violates the requirements you have expressed.  
On the face of it it violates "shall be written by a single image" given our
descriptive model for i/o, or under another interpretation it forces a deadlock.
> 
> But even if you don't want "problem" to be a conforming program...
> 
> ... the only difference between what my example above does, and a program that 
in two unordered segments in two images does
>   WRITE(*,*) 'X','1'
> and
>   WRITE(*,*) 'Y','2'
> is that my problem example forces the bad behaviour, whereas the other one just 
happens randomly depending on the real-time scheduling of the image resources.
With real-world examples and function references in the output lists, that badness
is not unrealistic.  Perhaps particularly on a big shared-memory machine where
images are being implemented by something like threads and there is contention for
resources from other programs.
> 
> I don't disagree in any way with your stated intent, but I don't think we have 
reached words that describe it yet.
> 
> Perhaps something more along the lines of "each record in the output file is 
written [NOT "shall be written"] by a single image as if no other image is writing
to the file while that record is being written"... those words aren't quite right,
but I think that that is probably the direction we need to be thinking in.
> 
> I hope we can word it without needing to go down to the level of describing the 
actions in ordered and unordered segments, but we need to think about what
happens in those cases.

You begin to convince me that we should require the user to ensure that there is 
an ordering of the i/o statements to one of these files. The behaviour that I 
have found useful might be available on some systems as an extension.

Cheers,

John.