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: 
 border2.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: Sat, 3 May 2014 20:54:33 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnlmals8.i0l.lithiumcat@nat.rebma.instinctive.eu>
References: <slrnlm6mkg.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com>
Injection-Date: Sat, 3 May 2014 20:54:33 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="76a49b86bc3e16725b7cfca3d85cb4c8";
 logging-data="17720"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX19v2B4z65RM4obOu3Udg+3N"
User-Agent: slrn/1.0.1 (FreeBSD)
Cancel-Lock: sha1:ch9jeZf38ZabkG1V7AtBm3MgXKE=
Xref: number.nntp.dca.giganews.com comp.lang.ada:186198
Date: 2014-05-03T20:54:33+00:00
List-Id: <comp.lang.ada>

On 2014-05-03, sbelmont700@gmail.com <sbelmont700@gmail.com> wrote:
> On Friday, May 2, 2014 4:42:56 AM UTC-4, Natasha Kerensikova wrote:
>> 
>> Is it safe to have many tasks performing operations concurrently on
>> constant objects?
>> 
>
> In the general case, no.  Suppose your constant object is of a private
> type T, which contains an access value to something else.  Some
> operation O might read and write to the other object in a non-task
> safe manner, and so invoking O from two different tasks might cause
> any number of fun shenanigans.

OK, it makes sense.

But then it would be useless to try to encapsulate such an operation in
a function of a protected object, right? Since protected function
provide concurrent access with the only restriction being private
members of the protected object being constant.

And more importantly, that means there is no way of guessing the safety
of concurrent reads without peeking into the implementation, right?

So if I happened to need concurrent read operations (e.g. because
sequencing them through a protected procedure is too inefficient), I
can't use the standard containers. Is that right?

That's quite a setback, having to reinvent containers for something as
weak as concurrent read capability...



Thanks for your help,
Natasha