(j3.2006) (SC22WG5.3725) Atomic stuff

Van Snyder Van.Snyder
Wed Dec 3 20:06:08 EST 2008

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.

More information about the J3 mailing list