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!feeder.eternal-september.org!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!news2.arglkargh.de!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Safety of unprotected concurrent operations on constant objects
Date: Wed, 7 May 2014 22:41:11 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <lkeucn$64k$1@loke.gir.dk>
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> <lyzjiw7h6c.fsf@pushface.org>
 <fRN9v.204655$Ng5.180587@fx17.iad>
 <slrnlmft61.i0l.lithiumcat@nat.rebma.instinctive.eu>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: loke.gir.dk 1399520472 6292 69.95.181.76 (8 May 2014 03:41:12 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Thu, 8 May 2014 03:41:12 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:19743
Date: 2014-05-07T22:41:11-05:00
List-Id: <comp.lang.ada>

"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnlmft61.i0l.lithiumcat@nat.rebma.instinctive.eu...
...
> But what about dereferencing an access value? Is it safe to concurrently
> dereference the same access value from multiple tasks?
>
> It's hard to imagine dereferencing a pointer to be unsafe, but as we all
> know access are more than mere pointers, with accessibility checks and
> custom storage pools and what not.

The language only allows specific things to *not* be task-safe. You can read 
9.10 and Annex A to find out what they are. (And then tell the rest of us, 
9.10 is impentrable. :-) In particular, if 9.10 doesn't include something in 
the possible erroneous execution, then it has to be task safe. (For the 
obvious reason that the language spells out what *doesn't* have to work --  
everything else has to work in all conditions.)

> By the way, are implicit subprograms calls, like the storage pool thing
> on dereference, also covered by the non-guarantee of concurrent read 
> safety?

Yes. There's nothing special about calls to Allocate or Finalize or similar 
routines.

                           Randy.