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!mx02.eternal-september.org!feeder.eternal-september.org!news.szaf.org!news.enyo.de!.POSTED!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: C versus Ada (once again :-)), was: Re: F-22 ADA Programming
Date: Tue, 04 Nov 2014 16:50:13 +0100
Message-ID: <87389z3qyy.fsf@mid.deneb.enyo.de>
References: <a510f410-56ea-46a6-9f3c-021a2389b936@googlegroups.com>
	<220f97ab-9aa2-4961-b140-2b271c3ab99a@googlegroups.com>
	<slrnm4ulto.nrc.lithiumcat@nat.rebma.instinctive.eu>
	<m2on9t$tv6$1@dont-email.me>
	<99759c3f-a35f-4745-a8fd-2fb6ab6fb1aa@googlegroups.com>
	<m2p0g5$4d0$1@dont-email.me>
	<48dc1630-8e7d-4e29-8bdd-53d74932d9d0@googlegroups.com>
	<m2pakq$99g$1@dont-email.me>
	<88a7f98c-55c2-4b5f-8a9d-c8b7512781c8@googlegroups.com>
	<m2ptm9$h8a$2@dont-email.me>
	<pgdzu6hi3mcu.kx0szqbevtow$.dlg@40tude.net>
	<m2r7k7$2m2$2@dont-email.me>
	<50cacb19-5d0b-4dbe-b91b-0b3b462913d6@googlegroups.com>
	<m2tnoi$j1q$4@speranza.aioe.org>
	<07d0ad94-160b-4873-ba1b-403e8c0bc420@googlegroups.com>
	<m2vlg9$onb$1@dont-email.me> <m31iit$74m$1@dont-email.me>
	<874mugsbhl.fsf@mid.deneb.enyo.de> <STS5w.353302$Hb3.343492@fx03.iad>
	<87wq7b3wv9.fsf@mid.deneb.enyo.de> <m3apnf$ckb$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: news.enyo.de 1415116213 16190 192.168.18.20 (4 Nov 2014 15:50:13 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:zs60Fn9K1kgzDhL/SNj3dEIjfNY=
Xref: news.eternal-september.org comp.lang.ada:23019
Date: 2014-11-04T16:50:13+01:00
List-Id: <comp.lang.ada>

* G. B.:

> On 04.11.14 14:42, Florian Weimer wrote:
>> The main challenge is to expose weaker (and therefore more efficient)
>> synchronization primitives.
>
> In view of the work on parallel loops of current Ada
> standardization: what algorithms will remain as
> not expressible with the help of parallel loops?

Anything that merely updates some global datastructure instead
processing large chunks of it, e.g., a storage pool, or a concurrent
hash table used for session IDs in a multi-threaded server
application.

> So that they will need more than Volatile and a fast
> Suspension_Object in order to be just as efficient?

No, for large multiprocessors, you need weaker ordering constraints (I
think Ada's signaling between tasks implies sequentially consistent
ordering, which is the most expensive variant), and it's best to avoid
suspension objects and other heavyweight synchronization primitives as
far as possible.