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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Safety of unprotected concurrent operations on constant objects
Date: Wed, 7 May 2014 09:40:45 +0200
Organization: cbb software GmbH
Message-ID: <1ujfeb1baw6ri.1iprdov55030o$.dlg@40tude.net>
References: <slrnlm6mkg.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <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>
 <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>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: G+aXx1XI67D34t54ibhUPQ.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:19727
Date: 2014-05-07T09:40:45+02:00
List-Id: <comp.lang.ada>

On Wed, 07 May 2014 08:49:08 +0200, Georg Bauhaus wrote:

> I opposed it,
> asking that there should exist something (in addition?) which is
> not universally (mut)exclusive, since some programmers
> may have reasons, and proof of safety, to want otherwise.)

It already exists:

   type Foo is record
       ...
   end record;

>>> So you ask programmers who *do* *know* that concurrent reads are
>>> safe (because they can *show* that concurrent reads are safe)
>>> to still use mutex and not just read concurrently even though
>>> the locks are quite unnecessary?
>>
>> No, it is you who is asking programmers to re-invent wheel.
> 
> Programmers may have to use pre-existing wheels (POs, tasks,
> simpler ...) to compose a solution.

They can even use C. What is the point?

>>>> I explained how task-safe primitive operations can be overridden remaining
>>>> safe.
>>>
>>> Here we are: *every* operation of a so protected container
>>> is run in mutex ways. The programmer does not have a choice.
>>> It may be the best one, or it may be prohibitively slow.
>>
>> He clearly has.
> 
> If the programmer can request a "protected new" object,

The choice is between requesting and not requesting this.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de