From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Sat Mar 30 15:11:14 2013
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id 6DDE5356DE5; Sat, 30 Mar 2013 15:11:14 +0100 (CET)
Delivered-To: sc22wg5@open-std.org
Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151])
	by www.open-std.org (Postfix) with ESMTP id 887B2356D4E
	for <sc22wg5@open-std.org>; Sat, 30 Mar 2013 15:11:13 +0100 (CET)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58067)
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25)
	with esmtpa (EXTERNAL:nmm1) id 1ULwUw-0005Y8-XB (Exim 4.72)
	(return-path <nmm1@hermes.cam.ac.uk>); Sat, 30 Mar 2013 14:11:10 +0000
Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk)
	with local (PRAYER:nmm1) id 1ULwUw-0003EG-7z (Exim 4.72)
	(return-path <nmm1@hermes.cam.ac.uk>); Sat, 30 Mar 2013 14:11:10 +0000
Received: from [87.115.144.83] by webmail.hermes.cam.ac.uk
	with HTTP (Prayer-1.3.5); 30 Mar 2013 14:11:10 +0000
Date: 30 Mar 2013 14:11:10 +0000
From: "N.M. Maclaren" <nmm1@cam.ac.uk>
To: "Bader, Reinhold" <Reinhold.Bader@lrz.de>
Cc: fortran standards email list for J3 <j3@mailman.j3-fortran.org>,
    sc22wg5 <sc22wg5@open-std.org>,
    "Van.Snyder@jpl.nasa.gov" <Van.Snyder@jpl.nasa.gov>
Subject: Re: [ukfortran] (SC22WG5.4955) AW: (j3.2006) AW: AW: AW: Thoughts on
 Reinhold's thoughts
Message-ID: <Prayer.1.3.5.1303301411100.11518@hermes-1.csi.cam.ac.uk>
In-Reply-To: <20130330115402.11CF3356DDA@www.open-std.org>
References: <20130329203623.0D66F356D96@www.open-std.org>
 <20130329212446.AD585356D97@www.open-std.org>
 <20130329231248.0A33D356DA7@www.open-std.org>
 <166ED263DF83324D9A3BA67FB6772B2B59F2B4D0@BADWLRZ-SWMBX11.ads.mwn.de>
 <Prayer.1.3.5.1303301046270.7686@hermes-1.csi.cam.ac.uk>
 <166ED263DF83324D9A3BA67FB6772B2B59F2B546@BADWLRZ-SWMBX11.ads.mwn.de>
 <20130330114121.E5517356DD8@www.open-std.org>
 <20130330115402.11CF3356DDA@www.open-std.org>
X-Mailer: Prayer v1.3.5
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

On Mar 30 2013, Bader, Reinhold wrote:
>> 
>>     3) To allow limited synchronisation between inside and outside,
>> whether by using atomics and SYNC MEMORY or otherwise
>> 
>> (1) is easy to validate, (2) doesn't introduce any consistency problems
>> though it might introduce deadlock, and (3) is the one I get twitchy
>> about.
>
> I would also be in favor of disallowing (3). In fact, usage of atomics 
> (as well as events) should also not be allowed across team boundaries if 
> they are to be generally efficient, for just the reasons you give.

It's not so much that they are inefficient, more that it's hard to define
what semantics they should have, implement those semantics, check that
they are honoured, and use them correctly.

Regards,
Nick Maclaren.