From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Safety of unprotected concurrent operations on constant objects
Date: Mon, 05 May 2014 09:39:39 +0100
Organization: A noiseless patient Spider
Message-ID: <lyzjiw7h6c.fsf@pushface.org>
References: <slrnlm6mkg.i0l.lithiumcat@nat.rebma.instinctive.eu>
	<7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com>
	<slrnlmals8.i0l.lithiumcat@nat.rebma.instinctive.eu>
	<lya9aybkxc.fsf@pushface.org> <lk41jr$1vl$1@dont-email.me>
	<slrnlmbs1n.i0l.lithiumcat@nat.rebma.instinctive.eu>
	<6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com>
	<slrnlmcoqd.i0l.lithiumcat@nat.rebma.instinctive.eu>
	<waw9v.109142$f85.65293@fx19.iad> <scy9v.1071029$2N5.142769@fx05.iad>
	<kxy9v.109149$f85.89664@fx19.iad>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx05.eternal-september.org;
 posting-host="6c8e46900abaabd1a3b7c03d9ac850ff";
	logging-data="8901"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+GX0Zl99CJYzfXpPmfIGt/T7xLhKDuB/8="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin)
Cancel-Lock: sha1:pxPU179DeguCfLG1jPlYDKHzu1M=
	sha1:Au/VelWqRNTfnFPzikFRna9mPhE=
Xref: news.eternal-september.org comp.lang.ada:19681
Date: 2014-05-05T09:39:39+01:00
List-Id: <comp.lang.ada>

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.

[1] http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-8-1.html
[2] http://www.ada-auth.org/standards/12aarm/html/AA-A-18.html#p5.m