From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3ccb707f4c91a5f2
X-Google-Attributes: gid103376,public
From: mazzanti@iei.pi.cnr.it (Franco Mazzanti)
Subject: Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again,
 Ada absent from DoD SBIR solicitation))
Date: 1996/11/25
Message-ID: <mazzanti-2511961115230001@131.114.200.115>#1/1
X-Deja-AN: 198569681
organization: IEI-CNR
newsgroups: comp.lang.ada
Date: 1996-11-25T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert A. Duff wrote:

">And of course it is quite clear that two writes to the same file using
 >Put_Line with a file argument are NOT covered by paragraph 3. So that's
 >mightly curious:
  >
 >    Put_Line (Standard_Output, "xxxx");
 >
 >appearing in two tasks is not covered, and could be erroneous, but
 >
 >    Put_Line ("xxxx");
 >
 >is OK. That seems quite weird to me, ...

 Agreed.  In my opinion, both of the above should be considered
 erroneous.  I said that in another article, and I also admitted that the
 RM doesn't clearly say so.  As you say, if one thinks the above should
 work, then one needs to worry about the granularity of interleaving."


I know I am an heretic for my views on this subject. 

However I think that it is quite incorrect to consider "Standard_Output"
as a shared variable. "Standard_Output" is a function call, and it very likely
to return an anonymous temporary object. AT least this is what one would
expect by reading the RM (unless File_Type is a "return-by-reference" type).

Only if we make use of the version of "Standard_Output" which returns a
"File_Access" object, then in two concurrent calls of

   Put_Line (Standard_Output.all, "xxxx"); 

we would really use a shared variable.

However, even in this case, the erroneousnees is not clearly implied by the
reference manual because the File_Type argument has mode IN. So, we have
sharing, but this sharing is safe because it is "read only".

The picture which the RM naturally provides (at least to a naive reader) is
the only two concurrent Close, Delete, Reset, Flush operations on the same
File_Type variable are erroneous for 9.10 (or the execution of any of
these
operations bin parallel with a Get_Line, Put_Line, ...) because these 
operations actually take a File_Type parameter of mode IN OUT.

I agree that some attributes associated to file objects are modified by get 
and put operations (file position information). However, this kind of data
is completely outside the user view, is part of the underlying implementation
of the I/O system and A(3) seem really to imply that concurrent calls of
Put_line should be thread-safe.

With the respect to the granularity of the interleaving, I do not think that
one needs to worry about it. 
Once it is stated clearly that the effects of Put_line need not be atomic 
(with respect to the externel effect and the update of the file position
attributes) it is perfectly acceptable that the EXTERNAL effect of two 
put_line operations results in some unspecified interleaving of the data.

But this is very different from allowing the concurrent execution of even 
the operations:

   Put_Line(My_file, "my-string");
   V:Count := Col(F);

to be erroneous and "thrash my hard disk".

Franco Mazzanti