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!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx01.iad.POSTED!not-for-mail
From: Brad Moore <brad.moore@shaw.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 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>
 <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> <xtDav.68151$7X2.15124@fx19.iad>
 <1jebi7cf92ak4.1trmstj8qi3wm.dlg@40tude.net> <zv4bv.5236$pa5.5140@fx23.iad>
 <1i6pyg077xlrv.vnwotzzgb0ut$.dlg@40tude.net> <nYobv.8538$116.7932@fx21.iad>
 <10pk27v48vhcb$.1qkf6roq2yzjn$.dlg@40tude.net> <RVObv.4489$TT7.3088@fx02.iad>
 <1qq0ryc8c4l2m.1driqwwiwwl02.dlg@40tude.net>
 <%vhcv.255737$s87.168969@fx11.iad>
 <fw1hrdv0jufx$.fetdmr8mer8o$.dlg@40tude.net> <qtqcv.27961$hv6.6727@fx17.iad>
In-Reply-To: <qtqcv.27961$hv6.6727@fx17.iad>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <30rcv.17381$Nf2.13630@fx01.iad>
NNTP-Posting-Host: 68.145.219.148
X-Complaints-To: internet.abuse@sjrb.ca
X-Trace: 1399995519 68.145.219.148 (Tue, 13 May 2014 15:38:39 UTC)
NNTP-Posting-Date: Tue, 13 May 2014 15:38:39 UTC
Date: Tue, 13 May 2014 09:38:28 -0600
X-Received-Bytes: 2785
X-Received-Body-CRC: 4190121536
Xref: news.eternal-september.org comp.lang.ada:19801
Date: 2014-05-13T09:38:28-06:00
List-Id: <comp.lang.ada>

On 14-05-13 09:01 AM, Brad Moore wrote:
> For example, you could fold the body of Unsafe_Search into the body of
> Safe_Search. Then you would be guaranteeing that there would be no way
> to circumvent the lock, as there is only the one entry point to your
> function. Your mutex lock function could then have the Task_Safe aspect.

On second thought this probably wouldn't work, or I can't think of an 
example of where it could work, since the Unsafe_Search likely modifies 
some global state.

So you'd probably have to wrap the data and function in a protected 
object, which would then be Task_Safe. That may be why Ada has PO's in 
the standard, but does not provide any mutex libraries like the one you 
suggest; They are too error prone. I'd be surprised if mutexes and scope 
locks like the one in your example wouldn't have been considered for 
inclusion in the standard at some point during the history of Ada.
Ada does provide the building blocks that programmers can create such 
abstractions however, which programmers are then free to use as they wish.