From owner-sc22wg5@open-std.org  Thu Dec  4 02:06:17 2008
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id B79A5C56CF8; Thu,  4 Dec 2008 02:06:17 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105])
	by www2.open-std.org (Postfix) with ESMTP id D1D0BC4596D
	for <sc22wg5@open-std.org>; Thu,  4 Dec 2008 02:06:15 +0100 (CET)
Received: from mprox3.jpl.nasa.gov (mprox3.jpl.nasa.gov [137.78.160.171])
	by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id mB416Cjh012424
	for <sc22wg5@open-std.org>; Thu, 4 Dec 2008 01:06:13 GMT
Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57])
	(authenticated bits=0)
	by mprox3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id mB4169QW018274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <sc22wg5@open-std.org>; Wed, 3 Dec 2008 17:06:11 -0800
Subject: Re: (j3.2006) (SC22WG5.3701) Atomic stuff
From: Van Snyder <Van.Snyder@jpl.nasa.gov>
Reply-To: Van.Snyder@jpl.nasa.gov
To: sc22wg5 <sc22wg5@open-std.org>
In-Reply-To: <493626D6.9020006@llnl.gov>
References: <20081203025222.12F4BC178E0@www2.open-std.org>
	 <493626D6.9020006@llnl.gov>
Content-Type: text/plain
Organization: Yes
Date: Wed, 03 Dec 2008 17:06:08 -0800
Message-Id: <1228352769.15904.614.camel@math.jpl.nasa.gov>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.2) 
Content-Transfer-Encoding: 7bit
X-Source-IP: math.jpl.nasa.gov [137.79.7.57]
X-Source-Sender: Van.Snyder@jpl.nasa.gov
X-AUTH: Authorized
Sender: owner-sc22wg5@open-std.org
Precedence: bulk


On Tue, 2008-12-02 at 22:27 -0800, Aleksandar Donev wrote:
> Hi Van,
> 
> > 1.  Provide an attribute for a variable that says accesses to it are
> > atomic.

> While this may be preferable to the use of intrinsics, it is also much
> more complex to get right, especially in terms of matching of the
> attribute across association (can you point a nonatomic pointer to an
> atomic, how about arrays, etc.).

Those kinds of problems don't exist.  Perhaps I should write some
proposed edits to make the idea clearer.

An ATOMIC attribute for a variable doesn't affect its representation: it
only affects how it is accessed or defined, within the scoping unit or
construct wherein it is specified.  It requires both atomic references
and atomic updates.  That's all.  If an atomic pointer is associated
with a nonatomic variable, references (updates) by way of the pointer
are atomic, and references (updates) by way of the variable are not.
Existing type, kind and rank rules would apply for pointer assignment.

> I prefer alternative mechanisms to specify atomic operations (notably an
> ATOMIC block), but, that was not the goal. The goal was to provide some
> simple mechanism for spin loops and the like without the problems of
> VOLATILE. It is a compromise, and nobody's first preference. Nothing
> wrong with that, IMO, especially since it is just two intrinsics and not
> something that fundamentally messes up the language for eternity.

An ATOMIC block would be equivalent to specifying the ATOMIC attribute
in a BLOCK for every variable referenced or defined within the BLOCK.
That's a somewhat bigger hammer than the ATOMIC attribute.