Version 1.7 of ai12s/ai12-0114-1.txt
!standard A(3/2) 14-10-02 AI12-0114-1/03
!class binding interpretation 15-06-08
!status Corrigendum 1-2012 14-07-15
!status WG9 Approved 14-10-20
!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 designated 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