Version 1.2 of ai12s/ai12-0114-1.txt

A(3) not only applies to nonoverlapping objects denoted by parameters passed by reference but also to nonoverlapping objects designed by parameters of access type.

A(3) mandates that "The implementation shall ensure that each language-defined subprogram is reentrant in the sense that concurrent calls on {any language-defined}[the same] subprogram perform as specified, so long as all parameters that could be passed by reference denote nonoverlapping objects."

The rule does not apply when overlapping objects designated by access parameters overlap. Hence such calls would need to be made reentrant, i.e. thread-safe, in all cases. Is this intended? [No.]

A possible solution is to extend A(3) to read

The implementation shall ensure that each language-defined subprogram is reentrant in the sense that concurrent calls on {any language-defined}[the same] subprogram perform as specified, so long as all parameters that could be passed by reference denote nonoverlapping objects {and all parameters of access type designate nonoverlapping objects}.

This solution is preferable to special-case rules that deal with each problematic interface individually. Luckily the rule is written such that in practice it will not impact any subprograms in which access parameters can access nonoverlapping objects safely.

Extend A(3) to read (inclusive of AI12-00052 changes):

The implementation shall ensure that each language-defined subprogram is reentrant in the sense that concurrent calls on {any language-defined}[the same] subprogram perform as specified, so long as all parameters that could be passed by reference denote nonoverlapping objects {and all parameters of access type designate nonoverlapping objects}.

Unfortunately, the issues that surround A(3), e.g., the alteration of file handles as part of IO operations, not only apply to parameters passed by reference, but also to parameters of access types passed by copy or copy-in/copy-out.

Most notably, 'Read, 'Write, 'Input and 'Output operate on access Ada.Streams.Root_Stream_Type'Class, causing the very same issues that accompany file handles in IO operations.

Other examples in predefined packages include: The types System.Storage_Pools.Subpools.Subpool_Handle, Interfaces.C.Strings.char_array_access and Interfaces.C.Pointers.Pointer used for parameters of subprograms, or the declaration of the parameter Interfaces.C.Pointers.Do_RPC.Result as an IN parameter.

The likelihood of the user encountering the problem in user code is demonstrated in the RM by the procedure Tapes.Copy using access parameters of mode IN with the clear intent to alter the object designed by one of the parameters.

While potential data races in user-written code are the responsibility of the user, the above examples show that the predefined packages also include interfaces that would be affected by data races when the same object is designated by access parameters of concurrent calls.

No ASIS effect.

An ACATS C-Test ought to ensure that no redispatching occurs in statically bound calls.

***************************************************************