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.200.35.34 with SMTP id a31mr507172qta.42.1494456974101;
        Wed, 10 May 2017 15:56:14 -0700 (PDT)
X-Received: by 10.157.46.178 with SMTP id w47mr185515ota.12.1494456974061;
 Wed, 10 May 2017 15:56:14 -0700 (PDT)
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!l39no322853qtb.0!news-out.google.com!m134ni1179itb.0!nntp.google.com!c26no526417itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 10 May 2017 15:56:13 -0700 (PDT)
In-Reply-To: <oeu831$m09$1@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=173.71.201.205;
 posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf
NNTP-Posting-Host: 173.71.201.205
References: <e8d229c0-317e-4f5a-8d54-cf56c3aede7a@googlegroups.com>
 <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com>
 <oep7mj$1g3f$1@gioia.aioe.org>
 <e87ac3c3-8390-4d1d-979d-0bcc7e4d3dde@googlegroups.com>
 <oeq60s$18c1$1@gioia.aioe.org>
 <7b0c08eb-be62-4d14-ae99-cad038ad0a62@googlegroups.com>
 <oeqmqm$7ho$2@gioia.aioe.org>
 <077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com>
 <oet6vt$5h1$1@franka.jacob-sparre.dk>
 <e92ada63-f623-437e-aec8-e69d5e3e4a7f@googlegroups.com>
 <oeu831$m09$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3edf3e1a-e823-40f5-9227-04642101895b@googlegroups.com>
Subject: Re: Portable memory barrier?
From: Jere <jhb.chat@gmail.com>
Injection-Date: Wed, 10 May 2017 22:56:14 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:46751
Date: 2017-05-10T15:56:13-07:00
List-Id: <comp.lang.ada>

On Wednesday, May 10, 2017 at 1:26:00 AM UTC-4, J-P. Rosen wrote:
> Le 10/05/2017 =C3=A0 02:51, Jere a =C3=A9crit :
> > Is there a method besides Atomic?  If I am implementing a generic FIFO =
(lock=20
> > free) and the FIFO elements are complex data types that may not be able=
 to be=20
> > atomic, do I have any other options or are protected objects my only wa=
y out?
>=20
> Protected objects, or for a lower level, Synchronous_Task_Control. I
> know that you want lock free algorithms, but out of curiosity, did you
> measure the cost of locking algorithms? IOW, is all of this worth the
> trouble?
I wasn't necessarily aiming for a specific speed/cost.  I know I can easily=
=20
find a standard task safe container and use that and it might be faster (or=
 at=20
least fast enough) on various platforms.  This is more for a different opti=
on=20
from the normal.  It might be faster on some platforms or slower, but it is=
=20
mostly meant to be a tool in toolkit.