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: 
 backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 07 May 2014 20:28:23 +0200
From: Georg Bauhaus <rm-host.bauhaus@maps.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>
	<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>
	<97a0996a-a593-4990-95e9-44f4e9070fd3@googlegroups.com>
	<5368b00d$0$6703$9b4e6d93@newsspool3.arcor-online.net>
	<lqsx31h1st5k.oag3lhs8dn2i$.dlg@40tude.net>
	<5368dc70$0$6708$9b4e6d93@newsspool3.arcor-online.net>
	<ye80u8yjop49.zttq1d7bi98f$.dlg@40tude.net>
	<53690cb8$0$6602$9b4e6d93@newsspool4.arcor-online.net>
	<63k39u59mmk8.eeonyygr5rjc$.dlg@40tude.net>
	<5369d765$0$6608$9b4e6d93@newsspool4.arcor-online.net>
	<1ujfeb1baw6ri.1iprdov55030o$.dlg@40tude.net>
	<536a1821$0$6706$9b4e6d93@newsspool2.arcor-online.net>
 <lyiophbhyz.fsf@pushface.org>
In-Reply-To: <lyiophbhyz.fsf@pushface.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <536a7b47$0$6702$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 07 May 2014 20:28:23 CEST
NNTP-Posting-Host: eaa1c961.newsspool3.arcor-online.net
X-Trace: DXC=O>Af8B?Hc5hf1oJaJ0@dmgMcF=Q^Z^V3h4Fo<]lROoRa8kF<OcfhCOkPj58fjGW;
 bhPCY\c7>ejVhg6ii; US6Nhoh=F@I\Jn=`m
X-Complaints-To: usenet-abuse@arcor.de
Xref: number.nntp.dca.giganews.com comp.lang.ada:186292
Date: 2014-05-07T20:28:23+02:00
List-Id: <comp.lang.ada>

On 07/05/14 19:45, Simon Wright wrote:
> "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
>
>> The "sequential checks" that handle tampering already add to Ada
>> containers being slow in comparison.
>
> To what?

GNAT's maps, for example, are slower than GNAT's own hash table
(the one that is not as easy to use as maps).

While Dmitry's "protected new" would be simple to use (if it
will work), I imagine containers that replace the defensive
checks for tampering etc. with contracts. The proof obligations
that follow will mean more work for users, but in return for
following the contract, concurrent reads can be safe and also
a little faster. At least the contract could make Element as
safe as reading array components in parallel.