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!feeder4.news.weretis.net!newsfeed.datemas.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Thu, 08 May 2014 12:30:45 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Safety of unprotected concurrent operations on constant objects
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>
 <t7a0jcl05g1h.11jb75b2jg1l7.dlg@40tude.net> <eT_9v.574$dr.264@fx27.iad>
 <83ha6vuynrzs.1jk08faxb8mnl.dlg@40tude.net> <xtDav.68151$7X2.15124@fx19.iad>
 <1jebi7cf92ak4.1trmstj8qi3wm.dlg@40tude.net>
In-Reply-To: <1jebi7cf92ak4.1trmstj8qi3wm.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <536b5cd4$0$6699$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 08 May 2014 12:30:44 CEST
NNTP-Posting-Host: ff20c390.newsspool2.arcor-online.net
X-Trace: 
 DXC=l\3JC9RLOI3=FQB?mjjV50A9EHlD;3Yc24Fo<]lROoR18kF<OcfhCO;WW8OgNdQ186nc\616M64>:Lh>_cHTX3j=ZbSk8Ncei;4
X-Complaints-To: usenet-abuse@arcor.de
Xref: news.eternal-september.org comp.lang.ada:19750
Date: 2014-05-08T12:30:44+02:00
List-Id: <comp.lang.ada>

On 08.05.14 10:20, Dmitry A. Kazakov wrote:
>> Containers maybe not in general, but a constant container object without
>> >tamper checks could easily be made to be task safe, for functions that
>> >query the container, as per the original OP's request.
> Yes, but this a very rare scenario (static container), which does not
> deserve special treatment.

Constant (non-static) views of containers abound, in particular
with big-data---data items being small or big. In fact, every
database-like structure frequently has two modes:

- reading, in order to gain insight (for filtering,  statistics,
   decision support ...),

- writing, updating the facts, adding "history", ...

Imagine some internet appliance, of which there are millions.
The better ones will have specialized processors. Each of them
will need access to the data, some for reading, some for writing.
How about each of them then relying on both the efficiency and
the task safety of tables (and associated interface)?

I think that scenarios like this might deserve special treatment.

I also imagine that image processing might use shared arrays,
though perhaps unbounded. They would become constant as soon as
all image data have been acquired and stored in them, ready
for inspection, or as input to later stages.

Maybe a scenario like this might deserve special treatment, too.