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.dca.giganews.com!nntp.giganews.com!goblin1!goblin2!goblin.stu.neva.ru!news.teledata-fn.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Tue, 06 May 2014 11:49:01 +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.4.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>
 <97a0996a-a593-4990-95e9-44f4e9070fd3@googlegroups.com>
In-Reply-To: <97a0996a-a593-4990-95e9-44f4e9070fd3@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <5368b00d$0$6703$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 06 May 2014 11:49:01 CEST
NNTP-Posting-Host: ef4e7939.newsspool3.arcor-online.net
X-Trace: DXC=9I;
 k:W0l86F2jYf>V4L0gLMcF=Q^Z^V3H4Fo<]lROoRA8kF<OcfhCOKD<=Jh[b_HGCnc\616M64>JLh>_cHTX3jMY]M9?UQAn`H
X-Complaints-To: usenet-abuse@arcor.de
Xref: number.nntp.dca.giganews.com comp.lang.ada:186260
Date: 2014-05-06T11:49:01+02:00
List-Id: <comp.lang.ada>

On 06.05.14 10:48, Alejandro R. Mosteo wrote:
> On Tuesday, May 6, 2014 10:11:07 AM UTC+2, Dmitry A. Kazakov wrote:
>>
>> If you limit it to primitive operations then much simpler to do this:
>>
>>     type My_Container is tagged ...; -- All operations are unsafe
>>
>>     type My_Safe_Container is protected new My_Container with null record;
>
> Ah, how have I longed for such a feature...

The usefulness, I think, of safe containers depends on whether or not
containers provide sufficient abstraction.

Convenience aside:

If the program computes with "just data", using more or less
nothing but "indexing", then containers might provide the
necessary (low) level of abstraction. If it's about STL style
"algorithms".

If the program uses containers only to provide some internal
storage, then it will naturally shield them. Its own
data structures (tagged types, say) will only Have-A container,
and not emphasize the container operations.  In this case, I think,
it is adequate to let the programmer place mutex as needed.
(Even re-entrant (owned) semaphores incur some overhead.)