Re: Safety of unprotected concurrent operations on constant objects

["Randy Brukardt" <randy@rrsoftware.com>]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyzjiw7h6c.fsf@pushface.org...
> Shark8 <OneWingedShark@gmail.com> writes:
>
>> On 05-May-14 15:23, Brad Moore wrote:
>>> In GNAT any read or write operations on a container that set tamper
>>> flags are ironically not task safe
>>
>> That seems very... odd.
>
> Rationale 05 8.1 [1] says (last para)
>
>   "The general rule is given in paragraph 3 of Annex A which says "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." So in other words we
>   have to protect ourselves by using the normal techniques such as
>   protected objects when container operations are invoked concurrently
>   on the same object from multiple tasks even if the operations are
>   only reading from the container."
>
> AARM12 A.18 (5.m) [2] says
>
>   "If containers with similar functionality (but different performance
>   characteristics) are provided (by the implementation or by a
>   secondary standard), we suggest that a prefix be used to identify the
>   class of the functionality: [...] "Ada.Containers.Protected_Maps"
>   (for a map which can be accessed by multiple tasks at one time);
>   [...]"
>
> Personally I'd like to see the implication (that a standard-compliant
> implementation of Containers need not be task-safe unless the Standard
> specifies that it must be) made more visible.

Of course this is true of all Ada language-defined packages -- the basic 
rule is found in Annex A (the introductory text). You have similar issues 
with Text_IO and all other I/O, and most other packages that aren't Pure. We 
decided not to expose the implicit sharing of some things (specifically the 
Environment_Variables and the Current_Directory), so those have to be 
task-safe (mainly because they already are on many target systems, and 
they're rarely performance-critical anyway).

The real problem is that very little in Ada outside of the built-in stuff is 
required to be task-safe. One of the goals of the parallel stuff is to make 
this sort of thing more explicit; but this all dates back to Ada 83. Ada 95 
made it more explicit to avoid the worst problems (there is a story about an 
Ada 83 compiler for which very basic stuff wasn't task safe). Indeed, there 
was a bug in Janus/Ada back in the day that made integer divide not 
task-safe (on early processors, divide was a software routine, and I had 
used a library-level temporary object. Bzzzzt!). But that explicitness 
didn't go very far, because no one wanted locking overhead to turn most Ada 
programs into dogs (especially those that don't use any tasks).

                                   Randy.