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!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 07 May 2014 16:04:07 +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>
In-Reply-To: <83ha6vuynrzs.1jk08faxb8mnl.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <536a3d57$0$6713$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 07 May 2014 16:04:08 CEST
NNTP-Posting-Host: 31f99f6a.newsspool2.arcor-online.net
X-Trace: DXC=9bc7YBJEMO6]E=H1Q9`787A9EHlD; 3Yc24Fo<]lROoR18kF<OcfhCO; ie@K:P@;
 PK>nc\616M64>:Lh>_cHTX3j=2b3DQV>4mg4
X-Complaints-To: usenet-abuse@arcor.de
Xref: number.nntp.dca.giganews.com comp.lang.ada:186288
Date: 2014-05-07T16:04:08+02:00
List-Id: <comp.lang.ada>

On 06.05.14 10:11, 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;
>
> When inherited from, the compiler would override each primitive operation
> and wrap it with a reentrant mutex taken. When an operation gets overridden
> its new body is wrapped. Calling operation within a protected action would
> be bounded error. At least the compiler would be able to maintain mutexes
> of such objects, e.g. order them to prevent deadlocks.

Incidentally, "protected new" is like what was planned for
the "separate" keyword of Eiffel, which stands for "separate
processor". So far, the outcome seems to be that after some
20 years, they have had to severely restrict the language,
in order to facilitate some intensely formal analysis of the
possibilities, and pitfalls.


class SQNTL          | separate class SQNTL
feature              | feature
    foo               |    foo
      require ...     |      require ...
      ensure ...      |      ensure ...
end                  |  end

The idea being that DbC would work in concurrent programs
in ways similar to how it works in sequential programs.