Erroneous concurrent operations on hidden objects

Erroneous concurrent operations on hidden objects

[Franco Mazzanti]

Can the following program be erroneous?

with Text_IO; use Text_IO;
procedure Main is
   task type  TT;
   task body TT is
   begin
     for I in 1..10 loop
        delay 1.0;
        Put("*");
     end loop;
   end TT;
   T1, T2: TT
begin
  -- the two tasks proceede and print in parallel
  null;
end Main;

The Annotated Reference manual, Section A, paragraph (3) says:

"3   The implementation shall ensure that each language defined
subprogram is reentrant in the sense that concurrent calls on the same
subprogram perform
as specified, so long as all parameters that could be passed by reference
denote nonoverlapping objects.

        3.a   Ramification:  For example, simultaneous calls to Text_IO.Put
        will work properly, so long as they are going to two different files.
        On the other hand, simultaneous output to the same file constitutes
        erroneous use of shared variables. 

        3.c   Ramification:  The rule implies that any data local to the
        private part or body of the package has to be somehow protected
        against simultaneous access."


From annotation 3.a it would seem that simultaneous calls to "Put"
working on the same "file" is likely to be erroneous.
However, in the above program there are no shared variables of type
FIle_Type. Actually, there are no shared variables at all.
Some shared reference to whatever structure describes the "standard output"
is likely to exist in the private part of the package.  
But in this case the annotation 3.c should apply. I.e. the program
above should not be erroneous.  
The same would be true if "Current_Output" were set to a different 
file other then "Standard_Output". So, in practice, safe I/O should
be supported for any kind of file, not just for "Standard_Output".


Let us now consider the following:

with Text_IO; use Text_IO;
procedure Main is
   F: File_Type;
begin
   Create(F,Out_File,"my-out-file");

   declare
      task type  TT;
      task body TT is
      begin
         for I in 1..10 loop
            delay 1.0;
            Put(F,"*");
         end loop;
       end TT;
   begin
      -- the two tasks proceede and print in parallel
      null;
   end;
end Main; 

In this case we have a shared variable (F) but this variable is
passed with mode "in" to the Put procedure. So this shared variable
should not create any problem.
If this is true, then which are cases considered when annotation 3.a 
was written?

Just to make the picture more complex, what if the File_Type is
implemented by a controlled type (which must be passed by reference).
In this case it would seem that A(3) does not apply. Would in this case
the Put(F,"*") operation be erroneous even if the parameter is 
passed with mode "in"?

Which other cases of concurrent operation on hidden structures can
be erroneous when performed in parallel?

E.g. concurrent evaluations the language defined allocator "new" of a
shared access type with default standard pool? 
(they will probably update some hidden object representing the pool)

Or, as it is being discussed in a separate thread, concurrent copying of
the same (unbounded) string? 
(we may concurrently update some hidden reference count)

Does any rule prevent an implementation to implement any language defined
private type (e.g. "Character_Set", "Bounded_String", "Character_Mapping")
with implicit garbage collection and unsafe reference counting?

------------------------------------------------------------
   Dr. Franco Mazzanti
   Istituto di Elaborazione della Informazione
   Via S.Maria 46, 56126 Pisa, ITALY
   Tel: +39-50-593447/593400, Fax: +39-50-554342
   e-mail: mazzanti@iei.pi.cnr.it
------------------------------------------------------------

Re: Erroneous concurrent operations on hidden objects

[Robert A Duff]

In article <mazzanti-1911961736550001@131.114.200.115>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>Can the following program be erroneous?

Execution of this program is erroneous.  Perhaps the RM doesn't explain
this as clearly as it should, but files are variables, including the
standard output file and so forth.

>with Text_IO; use Text_IO;
>procedure Main is
>   task type  TT;
>   task body TT is
>   begin
>     for I in 1..10 loop
>        delay 1.0;
>        Put("*");
>     end loop;
>   end TT;
>   T1, T2: TT
>begin
>  -- the two tasks proceede and print in parallel

[another example]
>In this case we have a shared variable (F) but this variable is
>passed with mode "in" to the Put procedure. So this shared variable
>should not create any problem.

Still erroneous.  Type File_Type is either passed by reference, or is
some sort of pointer.  The designated variable gets updated, and thus
this is erroneous.  Again, I won't swear that the RM is crystal clear on
this point.

>E.g. concurrent evaluations the language defined allocator "new" of a
>shared access type with default standard pool? 
>(they will probably update some hidden object representing the pool)

No, that's not erroneous.  I think the RM *is* clear on that point.  The
implementation has to do some sort of locking inside the allocator.

>Or, as it is being discussed in a separate thread, concurrent copying of
>the same (unbounded) string? 
>(we may concurrently update some hidden reference count)

If you assign to the same unbounded string in two unsynchronized tasks,
that's erroneous.  The issue being discussed in a separate thread was
when the two strings are not the same variable, but the implementation
is trying to optimize by sharing storage.

>Does any rule prevent an implementation to implement any language defined
>private type (e.g. "Character_Set", "Bounded_String", "Character_Mapping")
>with implicit garbage collection and unsafe reference counting?

Implicit gc is OK, but unsafe ref counting is not.

- Bob

Re: Erroneous concurrent operations on hidden objects

[Franco Mazzanti]

Robert A Duff Wrote:

 "Execution of this program is erroneous.  Perhaps the RM doesn't
 explain this as clearly as it should, but files are variables,
 including the standard output file and so forth.

 >with Text_IO; use Text_IO;
 >procedure Main is
 >   task type  TT;
 >   task body TT is
 >   begin
 >     for I in 1..10 loop
 >        delay 1.0;
 >        Put("*");
 >     end loop;
 >   end TT;
 >   T1, T2: TT
 >begin
 >  -- the two tasks proceede and print in parallel
 [...]
 >E.g. concurrent evaluations the language defined allocator "new" of
 >a shared access type with default standard pool? 
 >(they will probably update some hidden object representing the pool)

 No, that's not erroneous.  I think the RM *is* clear on that point.  The
 implementation has to do some sort of locking inside the allocator."



I still cannot see the difference between the case of two tasks
performing a "Put" operation on standard outut, where a hidden object
representing the "file" is concurrently updated, and the case of two tasks 
concurrently calling "new" (or an instance of unchecked deallocation) on 
the same storage pool, where a hidden variable associated to the pool 
is concurrently updated [RM-13.11(2)].

I recognize that the common intuition is that the first case is 
erroneous and the second not. However, I cannot see the way in which
these opposite conclusions can be drawn from the reference manual.

The issue of atomicity of "new" and "free" was raised in Ada83 (by
AI-00880, and AI-00447) but at that time they did not receive a final
answer. How can deduce that this problem has been solved in Ada95?

Probably I am missing something important inside the Reference Manual.
Can you show me what?

Franco

Re: Erroneous concurrent operations on hidden objects

[Robert A Duff]

In article <mazzanti-2011961559220001@131.114.200.115>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>I still cannot see the difference between the case of two tasks
>performing a "Put" operation on standard outut, where a hidden object
>representing the "file" is concurrently updated, and the case of two tasks 
>concurrently calling "new" (or an instance of unchecked deallocation) on 
>the same storage pool, where a hidden variable associated to the pool 
>is concurrently updated [RM-13.11(2)].

I agree that the RM isn't quite clear on this point, but I'm pretty sure
the above is the "intent".

- Bob