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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.36.160.135 with SMTP id o129mr4496465ite.24.1486854141981;
        Sat, 11 Feb 2017 15:02:21 -0800 (PST)
X-Received: by 10.157.20.145 with SMTP id d17mr1242394ote.18.1486854141958;
 Sat, 11 Feb 2017 15:02:21 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!e137no378653itc.0!news-out.google.com!15ni527itm.0!nntp.google.com!e137no379148itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sat, 11 Feb 2017 15:02:21 -0800 (PST)
In-Reply-To: <o7o3si$1dg6$1@gioia.aioe.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=184.68.184.90;
 posting-account=1A2ZjwoAAACv32zkEz8vnPUIVPXwW28q
NNTP-Posting-Host: 184.68.184.90
References: <c7c7fd16-9302-4ea0-99c0-c6c48c775348@googlegroups.com>
 <52b3faef-34b7-485f-98fb-6f488692ae9b@googlegroups.com>
 <74921d6a-8e52-437e-8485-1f0a77bcc0cc@googlegroups.com>
 <b07ab100-f6c1-4459-9e21-d75dccf9e9b6@googlegroups.com>
 <a2d4b333-4e89-4375-b5cf-68d848a70722@googlegroups.com>
 <7f2e7b06-d287-437c-835d-c4a9d53ea7e1@googlegroups.com>
 <o7np0i$iu$1@dont-email.me>
 <o7o3si$1dg6$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5b707d82-ecab-4d7f-bf04-099412e16913@googlegroups.com>
Subject: Re: Lock-Free stack in Ada SPARK
From: stevenselectronicmail@gmail.com
Injection-Date: Sat, 11 Feb 2017 23:02:21 +0000
Content-Type: text/plain; charset=UTF-8
Xref: news.eternal-september.org comp.lang.ada:33333
Date: 2017-02-11T15:02:21-08:00
List-Id: <comp.lang.ada>

On Saturday, February 11, 2017 at 2:40:23 PM UTC-8, Dmitry A. Kazakov wrote:
> On 2017-02-11 20:36, Jeffrey R. Carter wrote:
> > Perhaps someone will enlighten me.
> >
> > All of the lock-free structures that I've looked at involved busy
> > waiting on a memory location via an atomic test-and-set/compare-and-swap
> > operation.
> 
> Yes.
> 
> > To my mind, that's an implementation of a lock, and I don't understand
> > why these are considered lock free.
> 
> You are right. An implementation based on protected objects is clearly a 
> blocking.
> 
> Yet in its idea protected objects meant to be somewhere in-between. 
> Logically, at the application level, a protected action is considered 
> "instant" and thus logically it is "lock-free", provided the programmer 
> does not abuse it running cycles on the context of a protected action.
> 
> But it is not instant at the machine level. If the protected object 
> overhead were comparable to a few normal processor instructions and 
> would never cause any task losing the CPU, then it might be considered 
> "lock-free" both logically and physically. But it certainly not so on 
> most architectures.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Dmitry you seem confused. I don't use normal protected objects. I use the special Lock_Free pragma which allows to generate lock-free code for certain very restricted protected objects.