(j3.2006) Connecting more than one unit to a file
Bill Long
longb
Thu Dec 3 18:17:11 EST 2015
On Dec 3, 2015, at 4:58 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> On Thu, 2015-12-03 at 22:02 +0000, Bill Long wrote:
>> On Dec 3, 2015, at 3:17 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>>
>>> On Thu, 2015-12-03 at 21:12 +0000, Bill Long wrote:
>>>> On Dec 3, 2015, at 3:03 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>>>>
>>>>> On Thu, 2015-12-03 at 12:41 -0800, Van Snyder wrote:
>>>>>> On Thu, 2015-12-03 at 20:25 +0000, Lionel, Steve wrote:
>>>>>>> This was, more or less, my objection to this particular item - I felt
>>>>>>> it really didn't add much of value other than to make programs that
>>>>>>> did this processor-dependent rather than nonconforming. I was told
>>>>>>> that the difference was meaningful to some users - given that I chose
>>>>>>> to vote for it.
>>>>>>>
>>>>>>> I don't see a value in rescinding the change.
>>>>>>
>>>>>> The value in rescinding it now is that it's not yet in the standard, so
>>>>>> we won't need to process a raft of interps a few years from now.
>>>>>
>>>>> For example:
>>>>>
>>>>> The description of POS= in 9.10.2.22 describes the result value in terms
>>>>> of the file. If more than one unit is connected, and "inquire by unit"
>>>>> is used, wouldn't one want the value for that unit? 9.10.2.17 describes
>>>>> the NEXTREC= action in terms of "the connection"? Does that mean it
>>>>> gives the next record for the file if one uses "inquire by file" and the
>>>>> next record for the unit if one uses "inquire by unit?" It should say
>>>>> so. The description in 9.10.2.17 for NUMBER= says it returns the number
>>>>> of the unit connected to the file. Which unit number? All the
>>>>> inquiries for changeable modes have problems related to multiple
>>>>> connections. All the inquiries described in terms of "the connection,"
>>>>> e.g., ACCESS=, have the same problems.
>>>>
>>>>
>>>> Units are local. If we say that it is not allowed for a particular
>>>> image to connect more than one unit to a file, that would still allow
>>>> useful cases and avoid some of these issues. Multiple images would
>>>> still be allowed to connect units (one per image) to the same file,
>>>> which is what is minimally needed.
>>>
>>> That's not enough to make the INQUIRE statement descriptions work.
>>
>> Trying to integrate all of parallel I/O at this point is not
>> practical. It is becoming more clear why sticking with the current
>> blanket ?processor dependent? is much better for this revision.
>
> If we don't handle the problems now, they'll just become interps, which
> are more difficult to deal with.
>
> Making units local makes the NUMBER= specifier in INQUIRE work.
That?s good, since units are already local. Was that way in F2008. (2.3.4 "Each image has its own execution state, floating-point status (14.7), and set of data objects, input/output units, and procedure pointers.?)
> If
> there is only one connection per file per image, then all the INQUIRE
> specifiers that say "the connection" work. POS= needs work.
>
> Several of the specifiers say "If there is no connection...." That
> needs to be "If there is no connection for the image...." There are
> probably places under OPEN and CLOSE where "for the image" needs to be
> added to a description of "connection.?
Adding ?for the image? in the right places is certainly backwards compatible with F2008, and independent of whether the processor supports multiple connections to a file. If it solves problems with INQUIRE, I can go along with this.
>
>>> DO
>>> CONCURRENT is described by reference to "the file" so it's not clear it
>>> works in that case either.
>>
>> I think the issues with DO CONCURRENT interactions with INQUIRE are
>> not specific to multiple units being connected to a file.
>
> Take a look at 8.1.6.5p5 and get back to me. The problem exposed here
> is the same as the problem of writing to the same file from different
> images. Do we address this now, or respond to a pile of interps later?
Image segments are different from DO CONCURRENT iterations. The programmer has no control over the order in which DO CONCURRENT iterations execute, or whether the execute simultaneously. The user does have control over segment ordering. Any restriction about writing to a file from different images would need to take that into account. Although it seems odd to specify restrictions on the use of a facility the existence of which is processor dependent.
Cheers,
Bill
>
>>
>> Cheers,
>> Bill
>>
>>
>>
>>>
>>>> Cheers,
>>>> Bill
>>>>
>>>>
>>>>
>>>>>
>>>>> How many more of these obscurities, hidden in places other than the
>>>>> INQUIRE statement (for example, in DO CONCURRENT) are eventually going
>>>>> to be interps?
>>>>>
>>>>> It's better to drive a stake through its heart now.
>>>>>
>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Van Snyder
>>>>>>> Sent: Thursday, December 03, 2015 3:21 PM
>>>>>>> To: Bill Long <longb at cray.com>
>>>>>>> Cc: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
>>>>>>> Subject: Re: (j3.2006) Connecting more than one unit to a file
>>>>>>>
>>>>>>> The more processor-dependent stuff we add, the less "standard" we have.
>>>>>>>
>>>>>>> "Processor dependent" means "not standardized." It militates against portability.
>>>>>>>
>>>>>>> We should rescind the "more than one unit connected to a file" work item because it has too many problems that can only be repaired by adding "processor dependent" in more places.
>>>>>>>
>>>>>>> Vendors can continue to provide it as an extension.
>>>>>>>
>>>>>>> On Fri, 2015-10-30 at 21:07 +0000, Bill Long wrote:
>>>>>>>> On Oct 30, 2015, at 3:31 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>>>>>>>>
>>>>>>>>> 9.5.4p4 says it is processor dependent whether more than unit can be
>>>>>>>>> connected to a file.
>>>>>>>>>
>>>>>>>>> 9.5.6.1p8 prohibits it.
>>>>>>>>>
>>>>>>>>> Since the permission in 9.5.4p4 is new, and is newly remarked in A2,
>>>>>>>>> we can assume that not changing the prohibition in 9.5.6.1p8 to a
>>>>>>>>> processor dependency was an oversight.
>>>>>>>>
>>>>>>>> Looks that way. How about changing:
>>>>>>>>
>>>>>>>> "If a file is already connected to a unit, an OPEN statement on that file with a dierent unit shall not be executed."
>>>>>>>>
>>>>>>>> to either nothing (delete the sentence), or
>>>>>>>>
>>>>>>>> ?If a file is already connected to a unit, the effect of executing an
>>>>>>>> OPEN statement on that file with a different unit is processor
>>>>>>>> dependent.? {And add a line in Annex A}
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Assuming we wish to allow multiple units to be connected to a file,
>>>>>>>>> do we need further explanation of how nonadvancing and asynchronous
>>>>>>>>> output work if they are done simultaneously on more than one unit
>>>>>>>>> connected to the same file?
>>>>>>>>
>>>>>>>> We wish to allow vendors to allow this (which some already do). Beyond that, we didn?t intend to be more specific. As a practical matter, allowing multiple units (normally one per image) to connect to a file is much simpler if the file is open on all of the units for reading only. This is operationally similar to multiple independent programs opening the same file for read-only, which has been going on for years. Coordinating output to the same file is harder. Vendors are free to prohibit output as part of the ?processor dependent? umbrella.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Bill
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> J3 mailing list
>>>>>>>>> J3 at mailman.j3-fortran.org
>>>>>>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>>>>>>
>>>>>>>> Bill Long longb at cray.com
>>>>>>>> Fortran Technical Support & voice: 651-605-9024
>>>>>>>> Bioinformatics Software Development fax: 651-605-9142
>>>>>>>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> J3 mailing list
>>>>>>> J3 at mailman.j3-fortran.org
>>>>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> J3 mailing list
>>>>>> J3 at mailman.j3-fortran.org
>>>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> J3 mailing list
>>>>> J3 at mailman.j3-fortran.org
>>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>>
>>>> Bill Long longb at cray.com
>>>> Fortran Technical Support & voice: 651-605-9024
>>>> Bioinformatics Software Development fax: 651-605-9142
>>>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>>>>
>>>>
>>>
>>>
>>
>> Bill Long longb at cray.com
>> Fortran Technical Support & voice: 651-605-9024
>> Bioinformatics Software Development fax: 651-605-9142
>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>>
>>
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
More information about the J3
mailing list