(j3.2006) synchronizing I/O

[John Reid]

Robert Corbett wrote:
> John Reid wrote:
> 
>> Robert Corbett wrote:
>>
>>> The second paragraph of Section 13 of WG5/N1762 says that
>>> Fortran 2008 processors must implement record-level
>>> synchronization for OUTPUT_UNIT and ERROE_UNIT.  I have
>>> not found language in the draft standard that specifies
>>> that requirement.  Have I missed it, or is the language
>>> yet to be added?
>>
>>
>>
>> We seem to have somehow lost this bullet point that was in 9.3.3.2 of 
>> 08-007:
>>
>> "Each record shall be read or 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 transfers data to the file until 
>> the whole record has been transferred."
> 
> 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.

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.

The facility is available from both Cray and g95. I hope we can find words that 
preserve the intention without placing a big burden on implementors. Perhaps:

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

...............................................................................

"malcolm at nag-j.co.jp wrote:

 >> We seem to have somehow lost this bullet point that was in 9.3.3.2 of 08-007:
 >>
 >> "Each record shall be read or 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 transfers data to the file until the whole record has been
 >> transferred."
 >
 > That must have been me - I seem to have thought this had something to do with 
team i/o.  I can understand why.
 >
 >>> I am interested in seeing how record-level synchronization
 >>> interacts with nonadvancing I/O.
 >> I don't see a problem here.
 >
 > Try reading what data transfer statements do - they transfer data to/from the 
file.  The removed bullet point would mean locking the file from the first item 
transferred to it (by which we mean executing the data transfer statement and 
processing the list item) until the record is finished.
 >
 > John, and the quoted text, seems to be operating under the impression that 
READ and WRITE do data transfers to an internal buffer until a whole record is 
built up and then blat the whole thing to the file in one go.  That is not, in 
fact, how the i/o is described or indeed how some i/o subsystems actually work.
 >
 > Bob is absolutely right in his concern.  According to John's quoted text,
 >   WRITE(OUTPUT_UNIT,'(A)',ADVANCE='NO') 'x'
 > will lock OUTPUT_UNIT on all other images until the original image does a 
record-advancing operation.

I don't see this as a problem.
 >
 > Ugh.
 >
 > I'd happily reinstate the text if it were correct... obviously something 
needs to be done but the wording needs to be much more careful.

See my suggestion above. I have sent a draft 09-119r2 to Bill.

John.