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: Tue, 13 May 2014 10:56:55 +0200
Organization: cbb software GmbH
Message-ID: <fw1hrdv0jufx$.fetdmr8mer8o$.dlg@40tude.net>
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>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: QTaafVZuunHujkJPndFR7g.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:19797
Date: 2014-05-13T10:56:55+02:00
List-Id: <comp.lang.ada>

On Mon, 12 May 2014 22:50:03 -0600, Brad Moore wrote:

> I lumped task safe programs with while loops into the 
> Potentially_Blocking category, because while loops can be used to 
> implement busy spin-loops, which can be considered a form of blocking.

Loops are used in many (if not most) lock-free algorithms. They have
bounded time, because the loop condition is that the task has been
preempted during execution of the loop body, which may happen only once,
provided scheduling is any reasonable.

>> What I had in mind are designs like:
>>
>> type T is record
>>     M : aliased Mutex;
>>     ...
>> end record;
>>
>> A safe operation on this type looks like:
>>
>>     procedure Safe_Search (X : in out T; ...) is
>>         Lock : Holder (T.M'Access);
>>     begin
>>         Unsafe_Search (X, ...);
>>     end Safe_Search;
>>
>> Here safe operations call to unsafe ones all the time and never do each
>> other because M is not reeentrant.
> 
> Thanks for the example. A good case to consider. By the rules I'm 
> thinking of, this would not be a task-safe construct however, which I 
> think is rightly so.
> 
> The Task_Safe attribute is about subprograms that can be proven to be 
> safe. This construct is unsafe, because it doesn't guarantee that there 
> aren't direct concurrent calls to Unsafe_Search happening while inside 
> the body of Safe_Search. (It would probably be too difficult to prove, 
> and so its better to assume the worst, when it comes to safety.) 
> Therefore Safe_Search is also not a task-safe call.

This is why I consider these attributes useless as they would work for
marginal cases only.

[...]

The rules you are proposing seem to me focusing on rather atomicity than
task safety.

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