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

Unformatted version of ai12s/ai12-0114-1.txt version 1.4
Other versions for file ai12s/ai12-0114-1.txt

!standard A(3/2)          14-07-15 AI12-0114-1/02
!class binding interpretation 15-06-08
!status Corrigendum 2015 14-07-15
!status ARG Approved 7-0-0 14-06-28
!status work item 14-06-08
!status received 14-06-08
!priority Low
!difficulty Easy
!qualifier Omission
!subject Overlapping objects designated by access parameters are not thread-safe
!summary
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.
!question
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.]
!recommendation
A(3) need to be extended so that overlapping objects are excluded, whether they're passed by reference or designated by an access value.
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.
!wording
Modify A(3) (including changes from AI12-0052-1):
The implementation shall ensure that each language-defined subprogram is reentrant in the sense that concurrent calls on any language-defined subprogram perform as specified, so long as all {objects that are denoted by} parameters that could be passed by reference {or designated by parameters of an access type are}[denote] nonoverlapping [objects].
!discussion
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.
!corrigendum A(3)
Replace the paragraph:
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.
by:
The implementation shall ensure that each language-defined subprogram is reentrant in the sense that concurrent calls on any language-defined subprogram perform as specified, so long as all objects that are denoted by parameters that could be passed by reference or designated by parameters of an access type are nonoverlapping.
!ASIS
No ASIS effect.
!ACATS test
An ACATS C-Test ought to ensure that no redispatching occurs in statically bound calls.
!appendix

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

Questions? Ask the ACAA Technical Agent