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

Van Snyder Van.Snyder
Wed Dec 3 18:39:57 EST 2008


On Tue, 2008-12-02 at 22:27 -0800, Aleksandar Donev wrote:
> 
> > 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.).

The details of this are in atomic_1.txt, attached.  This requires more
ubiquitous changes than I would have liked, but it is still less volume
than introducing two intrinsic subroutines and a new class of intrinsic
procedures.

> The other two ideas, while possibly technically useful, have nothing
> to do with ATOMIC. Until Fortran proper has accessors/updaters their
> use for atomic operations is out of the question.

One of the other ideas was to use <designator>%atomic.  The details of
that are in atomic_2.txt, also attached.  This is quite a bit simpler
than either atomic_1.txt or 08-297r1.

Fortran already has accessors for complex parts.  This would be yet
another special case, which also would (and should) have been handled by
introducing the general syntactic mechanisms.  Array references and
definitions are accessors that use normal procedure invocation syntax,
and component references and definitions are accessors that use
type-bound invocation syntax, both of which the compiler knows how to
write and inline.

Has anybody actually read "Uniform referents: An essential property for
a software engineering language" by D. T. Ross (In J. T. Tsou (Ed)
"Software Engineering", Academic Press, 1969), or "On the problem of
uniform references to data structures" by Charles M. Geschke and James
G. Mitchell (IEEE Trans. Softw. Eng. SE-1, 2 June 1975), and compared
the consequences of what they recommend with the consequences of what
David Parnas recommended in "On the criteria for decomposing programs
into modules" (CACM 15, 12, December 1972)?

-- 
Van Snyder                    |  What fraction of Americans believe 
Van.Snyder at jpl.nasa.gov       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.
-------------- next part --------------
[2.2:R212], add "<<or>> <atomic-stmt>" after "<<or>> asynchronous-stmt>".

[4.5.3.2:R437], add "<<or>> ATOMIC" after "<<or>> ALLOCATABLE".

Jim might want this one:

C449a A component of a sequence type, or of a type with the BIND(C)
      attribute, shall not have the ATOMIC attribute.

[5.2.1:R502], add "<<or>> ATOMIC" after "<<or>> ASYNCHRONOUS".

[New] 5.3.4a ATOMIC attribute

The ATOMIC attribute affects how a variable having that attribute is
referenced or defined.

A variable may have the ATOMIC attribute in some scoping units or BLOCK
constructs without necessarily having it in other scoping units or BLOCK
constructs.

If a variable has the ATOMIC attribute within a BLOCK construct or
scoping unit

o a reference to it within that construct or scoping unit produces the
  entirety of its value as if instantaneously, and

o defining it within that construct or scoping unit defines the
  entirety of its value as if instantaneously,

without interfering with or interference from processes defined by
means other than Fortran or from other images.

C517a ATOMIC shall not be specified for an entity that is not a
      variable.

C517b A variable with the ATOMIC attribute shall be of integer type
      with kind ATOMIC_INT_KIND or of logical type with kind
      ATOMIC_LOGICAL_KIND, where ATOMIC_INT_KIND and ATOMIC_LOGICAL_KIND
      are named constants from the intrinsic module ISO_FORTRAN_ENV.

Maybe Jim would like to have this too:

C517c A variable with the ATOMIC attribute shall not be storage
      associated (5.7).

NOTE 5.4a
  Suppose a processor represents LOGICAL(ATOMIC_LOGICAL_KIND) using two
  octets having values (in hexadecimal) either Z'0000' or Z'FFFF'.  A
  reference to or definition of such a variable within a construct or
  scoping unit where it has the ATOMIC attribute would always produce
  one of those values, and never produce either Z'00FF' or Z'FF00'.

[New] 5.4.3a ATOMIC statement

R528a> <atomic-stmt> <<is>> ATOMIC :: <object-name-list>

The ATOMIC statement specifies the ATOMIC attribute (5.2.4a) for a list
of variables.

[8.1.3.3p1] Insert ", ATOMIC," after "ASYNCHRONOUS".

[8.1.3.3p2] Insert ", ATOMIC," after "ASYNCHRONOUS".

[8.5.1p6] Replace "that is ... defined" by "that has the ATOMIC
attribute within a BLOCK construct or scoping unit may be referenced
within that construct or scoping unit during the execution of a segment
that is unordered relative to the execution of the segment in which the
coarray is defined, provided the coarray has the ATOMIC attribute in the
segment where it is defined".

[8.5.1:Note 8.30] Replace "volatile" by "atomic".

[8.5.1:Note 8.31] Replace "volatile" by "atomic" twice.

[8.5.5:Note 8.38] Replace "VOLATILE" by "ATOMIC".

[11.2.2p2] Insert ", ATOMIC," after "ASYNCHRONOUS".

[11.2.2p9] Insert ", ATOMIC," after "ASYNCHRONOUS".

[C1116] (if Jim agrees) Insert ", ATOMIC," after "ASYNCHRONOUS".

[12.3.2.2p1] Insert ", ATOMIC (5.3.4a)," after "ASYNCHRONOUS (5.3.4)".

[12.4.2.2p1(2)(a)] Do we need anything here?  Why are ASYNCHRONOUS and
VOLATILE here?  These are explicitly local specifications.

[12.5.2.4p18] I don't think ATOMIC needs to be mentioned here.

[C1237-9] I don't think ATOMIC needs to be mentioned here.

[NOTE 12.27] I don't think ATOMIC needs to be mentioned here.

[16.4p1] Insert ", ATOMIC," after "ASYNCHRONOUS".

[16.5.1.4p1] Insert ", ATOMIC," after "ASYNCHRONOUS".

[NOTE 16.7] Insert ", ATOMIC," after "ASYNCHRONOUS" thrice.

[16.6.5(26)] I don't think ATOMIC needs to be mentioned here.

-------------- next part --------------
[R601] Insert "<<or>> <atomic-indicator>" after "<<or>> <array-section>".

[New] "6.4.2a Atomic indicator

R613a <atomic-indicator> <<is>> <designator> % ATOMIC

C618a The <designator> shall be of type integer with kind
      ATOMIC_INT_KIND or of type logical with kind ATOMIC_LOGICAL_KIND,
      where ATOMIC_INT_KIND and ATOMIC_LOGICAL_KIND are named constants
      from the intrinsic module ISO_FORTRAN_ENV.

Maybe Jim would like to have this too:

C618b The <designator> shall not be storage associated (5.7), or a
      component of an object of a sequence type (4.5.2.3) or of a type
      with the BIND(C) attribute.

An atomic indicator specifies that

o referencing the designated entity produces the entirety of its value
  as if instantaneously, and

o defining the designated entity defines the entirety of its value as
  if instantaneously,

without interfering with or interference from processes defined by
means other than Fortran or from other images.

NOTE 6.5a
  Suppose a processor represents LOGICAL(ATOMIC_LOGICAL_KIND) using two
  octets having values represented by either Z'0000' or Z'FFFF'.  An
  atomic reference to or definition of such an object would always
  produce one of those values, and never produce either Z'00FF' or
  Z'FF00'."

Should definitions of coarrays or coindexed objects using an atomic
designator be specified to include the effect of SYNC MEMORY before and
after the definition?  This would simplify NOTE 8.38.

[8.5.1p6] Replace the first sentence of the paragraph:

"An atomic (6.4.2a) reference to a coarray or coindexed object is
permitted during execution of a segment that is unordered relative to
the execution of a segment in which an atomic definition of it occurs."

[NOTE 8.38]
Delete ",VOLATILE"
Replace "LOCKED[Q] = .FALSE." by "LOCKED[Q]%ATOMIC = .FALSE"
Replace "WHILE (LOCKED)" by "WHILE ( LOCKED%ATOMIC )"
More simplification is possible if atomic definitions include the effect
of SYNC MEMORY before and after the definition.

[Same 13.8.2.1a,b as in 08-297r1]



More information about the J3 mailing list