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,9e0bbf455a705f51,start X-Google-Attributes: gid103376,public From: mazzanti@iei.pi.cnr.it (Franco Mazzanti) Subject: Erroneous concurrent operations on hidden objects Date: 1996/11/19 Message-ID: #1/1 X-Deja-AN: 197455139 organization: IEI-CNR newsgroups: comp.lang.ada Date: 1996-11-19T00:00:00+00:00 List-Id: 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 ------------------------------------------------------------