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: 
 border1.nntp.dca3.giganews.com!backlog3.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!news.stack.nl!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Oberon and Wirthian languages
Date: Sat, 26 Apr 2014 09:36:11 +0200
Organization: cbb software GmbH
Message-ID: <1zhiqb89npa6$.1z9j4otjchcb.dlg@40tude.net>
References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net>
 <lic17o$re4$1@dont-email.me> <8761m535e4.fsf_-_@ludovic-brenta.org>
 <lj3540$m81$1@dont-email.me> <lj3nao$u22$2@dont-email.me>
 <lj4de1$jql$1@dont-email.me> <ly7g6hamsw.fsf@pushface.org>
 <lj5n4g$jse$1@dont-email.me> <brntbeFnfgcU1@mid.individual.net>
 <lj6kfg$jhs$1@dont-email.me> <lj6uhp$7dd$1@loke.gir.dk>
 <lj8aug$43b$1@dont-email.me> <ly61lzrciv.fsf@pushface.org>
 <lj9lbm$cig$1@dont-email.me> <brsggrFmd3gU1@mid.individual.net>
 <ljbmfm$j7u$1@dont-email.me> <brt9ftFrnkaU1@mid.individual.net>
 <ljce8q$qpb$1@loke.gir.dk> <ljekbl$bbt$1@dont-email.me>
 <ljeljn$sb3$1@loke.gir.dk> <bs121aFksntU1@mid.individual.net>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: AuYlnUSfTZrfhAkRjyySpQ.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
X-Original-Bytes: 3129
Xref: number.nntp.dca.giganews.com comp.lang.ada:186101
Date: 2014-04-26T09:36:11+02:00
List-Id: <comp.lang.ada>

On Sat, 26 Apr 2014 09:29:04 +0300, Niklas Holsti wrote:

> The 2011 C standard goes into various memory order semantics in great
> detail, not just "atomic". As I (weakly) understand it, that is
> necessary or useful for implementing lock-free and wait-free
> synchronization on modern architectures.

Yes!

> Do you see any need to extend Ada in that direction?

I certainly do, because I am using lock-free containers in Ada.

Some lock-free stuff can be implemented using pragma Atomic. Though there
are serious problems regarding portability. Unfortunately the standard does
not require that Atomic were accepted to all scalar types. [*]

Many lock-free operations require more than merely pragma Atomic, e.g.
compare and swap etc.

Though I find the selection used in C++11 __atomic built-ins strange and
rather difficult to use. I used it to work around GNAT's refusal to
atomically access 64-bit integers under 32-bit Windows/Linux.

Regarding original proposal, maybe I missed something, but I don't find it
useful in the case of hardware I/O, except maybe for very specific cases.
The reason is that reading from a hardware register is often impossible or
else has a physical side effect. In no way it can be done atomically with
the consequent read. We don't want to lock the whole machine for many
cycles? Hardware registers are very slow. When the copy of the register is
supposed to be stored elsewhere in RAM, then where is a problem?

----------------
* When the machine cannot load or store atomically, the compiler can always
fall back to a built-in protected object.

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