Re: Erroneous concurrent operations on hidden objects

[mazzanti@iei.pi.cnr.it (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