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: 
 border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Newsgroups: comp.lang.ada
Subject: Re: Safety of unprotected concurrent operations on constant objects
Date: Mon, 5 May 2014 20:29:53 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnlmft61.i0l.lithiumcat@nat.rebma.instinctive.eu>
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>
Injection-Date: Mon, 5 May 2014 20:29:53 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="76a49b86bc3e16725b7cfca3d85cb4c8";
 logging-data="29486"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX18JpC8JCLEZYUAUxLj5pmJ5"
User-Agent: slrn/1.0.1 (FreeBSD)
Cancel-Lock: sha1:OmWzFX9G8RMsFBNiDJ3RY5rOyIg=
X-Original-Bytes: 3046
Xref: number.nntp.dca.giganews.com comp.lang.ada:186255
Date: 2014-05-05T20:29:53+00:00
List-Id: <comp.lang.ada>

On 2014-05-05, Brad Moore <brad.moore@shaw.ca> wrote:
>   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 parameters that could be 
> passed by reference denote nonoverlapping objects.

OK, so any concurrent access of an object through standard subprograms
is unsafe.

> Another relevant RM paragraph is;
>
> RM 9.10(11-15) which starts;
>
> "Given an action of assigning to an object, and an action of reading or 
> updating a part of the same object (or of a neighboring object if the 
> two are not independently addressable), then the execution of the 
> actions is erroneous unless the actions are sequential."

And any write makes anything else unsafe on the same object.


Now the question is, what about the rest?

Does it mean any concurrent reads of the same object, without involving
any subprogram call, is safe?

At least RM 9.10 strongly implies that array indexing is task-safe.

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.

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