(j3.2006) synchronizing I/O

[malcolm at nag-j.co.jp]

Hi John,

thanks for the clarification of intent.

> > I assume no other image could do an ALL STOP, a BACKSPACE, a CLOSE,
> > a FLUSH, some INQUIREs, an OPEN, or a REWIND either.  It might be
> > argued that an endfile record is data, so the statement above might
> > cover that case.  A WAIT and most forms of INQUIRE might be OK,
> > depending on how I/O synchronization is implemented.
> > 
> > Bob Corbett
> 
> I don't think there is any problem with ALL STOP, which initiates error 
> termination. [32:15-16] says "If an image initiates error termination, all other 
> images that have not already initiated termination initiate error termination."
> 
> Yes, we have overlooked the other cases. I would never dream of doing any of 
> them to default output or error output.

FLUSH is quite common I should think.  I don't see anything undreamworthy about INQUIRE either.

> 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

>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.

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.

Cheers,
-- 
..............Malcolm Cohen, J3 meeting, Las Vegas.

P.S. Cursed jet lag!