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!newsfeed.datemas.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 07 May 2014 15:45:47 +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>
 <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>
 <5os0j7jd5moe.1eevhoxwpnpe5.dlg@40tude.net>
In-Reply-To: <5os0j7jd5moe.1eevhoxwpnpe5.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <536a390c$0$6706$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 07 May 2014 15:45:48 CEST
NNTP-Posting-Host: 0fadf4c5.newsspool2.arcor-online.net
X-Trace: 
 DXC=1LA=FGX??5<]E=H1Q9`787A9EHlD;3Yc24Fo<]lROoR18kF<OcfhCO;C=LIOMLmjO0nc\616M64>:Lh>_cHTX3j=n\fQ1eniC38
X-Complaints-To: usenet-abuse@arcor.de
Xref: news.eternal-september.org comp.lang.ada:19734
Date: 2014-05-07T15:45:48+02:00
List-Id: <comp.lang.ada>

On 07.05.14 14:14, Dmitry A. Kazakov wrote:
> On Wed, 07 May 2014 13:25:21 +0200, G.B. wrote:
>
>> On 07.05.14 09:40, Dmitry A. Kazakov wrote:
>>
>>> They can even use C. What is the point?
>>
>> The point is that
>>
>> IF programmers want task-safety, and
>> IF programmers need to respect timing,
>> -----------
>> THEN programmers may need to build safe solutions
>> without "protected new".
>
> I don't see where that follows from.

"Specification:

1. The concurrent program shall access X safely.
2. It shall do so within at most N µs."

> Programmers may need do it without
> dynamic memory allocation, unconstrained types, tasking, exceptions
> whatever. Remove them from the language and anything else they may need go
> without. Then we'll talk.

Programmers do work in such restricted environments,
for the most part, when using SPARK. Ravenscar was
made to be more efficient than full Ada tasking.
Ada people talk about this.

>> The point is that, with "protected new", they cannot get
>> their job done, in this case.
>
> Which case exactly?

The case which is again listed under "Specification" above.


> As well as between drinking beer or not drinking beer,

Whether or not concurrent reads of Ada containers are both
safe and fast seems unrelated to drinking. Well, unless a drunken
programmer is the cause and the solution of every problem.