!standard C.06 (07) 02-01-23 AI95-00272/01 !class binding interpretation 01-09-05 !status ARG Approved 6-0-0 02-02-12 !status work item 02-01-23 !status received 01-08-21 !qualifier Error !priority Medium !difficulty Medium !subject Pragma Atomic and slices !summary A slice of an atomic array type is not (necessarily) an atomic object. !question C.6(7) states that "An atomic object (including a component) is one to which a pragma Atomic applies, or a component of an array to which a pragma Atomic_Components applies, or any object of an atomic type." "Any object" includes a slice (see 3.3(12)). Consider for instance: type A is array (1..4) of Character; pragma Atomic (A); -- Supported? X : A; On a 32-bit machine, you would think that supporting pragma Atomic on this type is straightforward, until you realize that "any object" includes a slice like X(1..3), which is impossible to access atomically unless the machine also has 24-bit instructions, which is unlikely to say the least. !recommendation (See Wording.) !wording Replace the second sentence of C.6(7) by: An atomic object (including a component) is one to which a pragma Atomic applies, or a component of an array to which a pragma Atomic_Components applies, or any object of an atomic type, other than objects obtained by evaluating a slice. !discussion Slices should behave like components for the purposes of atomicity. That is, a component or slice of an atomic thing is not necessarily atomic. There is one subtlety associated with parameters. Consider: type Arr is array (...) of Component; pragma Atomic (Arr); procedure P (X : Arr) is ... If the first subtype, Arr, is unconstrained, then X may designate a slice at execution time. So in order to determine if an object is a slice, an implementation may need to do some run-time processing. This is unfortunate, but then support of pragma Atomic for unconstrained array is problematic anyway. Note that in the case where Arr is constrained, passing a (non-trivial) slice as the actual parameter for X will raise Constraint_Error, so an implementation can assume, in the body of P, that it is not dealing with a slice. Of course, when we say that a slice is not an atomic object, this doesn't mean that an implementation cannot read/update it atomically. It only means that it doesn't have to. !corrigendum C.6(07) @drepl An @i type is one to which a pragma Atomic applies. An @i object (including a component) is one to which a pragma Atomic applies, or a component of an array to which a pragma Atomic_Components applies, or any object of an atomic type. @dby An @i type is one to which a pragma Atomic applies. An @i object (including a component) is one to which a pragma Atomic applies, or a component of an array to which a pragma Atomic_Components applies, or any object of an atomic type, other than objects obtained by evaluating a slice. !ACATS test It is unclear whether this can be tested. !appendix From: Pascal Leroy Sent: Tuesday, August 21, 2001 4:03 AM I am in the process of beefing up support for pragma Atomic in our compiler, and I am running into what I believe to be a problem in the definition of that pragma for arrays. RM95 C.6(7) states that "An atomic object (including a component) is one to which a pragma Atomic applies, or a component of an array to which a pragma Atomic_Components applies, or any object of an atomic type." It is the last part of this sentence that is bothering me, because "any object" includes a slice (see RM95 3.3(12)). Consider for instance: type A is array (1..4) of Character; pragma Atomic (A); -- Supported? X : A; On a 32-bit machine, you would think that supporting pragma Atomic on this type is straightforward, until you realize that "any object" includes a slice like X(1..3), which is impossible to access atomically unless the machine also has 24-bit instructions, which is unlikely to say the least. This would seem to make it impossible to support pragma Atomic on arrays with Length > 2, so surely we have a problem somewhere... **************************************************************** From: Robert Duff Sent: Sunday, August 26, 2001 3:52 PM > This would seem to make it impossible to support pragma Atomic on arrays > with Length > 2, so surely we have a problem somewhere... Surely slices should behave like components here. That is, a component or slice of an atomic thing is not necessarily atomic. I agree with Pascal that there's a problem with the RM wording, here. **************************************************************** From: Robert Dewar Sent: Sunday, August 26, 2001 4:00 PM Right, obviously slices of atomic arrays are not atomic in general, so this is just an RM word play excercdise to fix this so that the bug in the RM is dealt with, I see no impact on the language, since the intent is obvious. **************************************************************** From: Pascal Leroy Sent: Monday, August 27, 2001 2:59 AM > Surely slices should behave like components here. That is, > a component or slice of an atomic thing is not necessarily > atomic. I agree with Pascal that there's a problem with the > RM wording, here. There is one subtlety, though. If the first subtype is unconstrained, then you do not necessarily know whether you are operating on a slice or the whole array (think of a parameter of the unconstrained first subtype, and try to generate code for the subprogram body). This might be a red herring, though, as I don't see what could possibly be the meaning of Atomic for unconstrained first subtypes (we certainly don't plan to support this case). **************************************************************** From: Robert Dewar Sent: Sunday, August 26, 2001 4:49 AM It *is* a red herring :-) ****************************************************************