(j3.2006) (SC22WG5.3746) [ukfortran] Atomic stuff
Thu Dec 4 21:51:20 EST 2008
Jim Xia wrote:
> > Any vendor who allows those as extensions can do whatever they like
> > atomic.
> Fair. If there weren't any customers requesting this, we wouldn't
> have supported it either. Actually I wasn't worried about sequence
> statement because I think anyone applying atomic operations on storage
> associated entities is clearly out of his mind.
> What I'm really concerned about are structure components. For a
> sequence derived type, we don't do any padding and it becomes
> equivalent to a C struct in pack mode.
Well, don't do that for atomic kind then.
No-one is forcing anyone to do anything impossible here. If atomic
accesses have to be 32-bits and aligned to prime number addresses
greater than 2**32, just set INT_ATOMIC_KIND or whatever it's called to
666 and have kind 666 do that.
No-one says that INT_ATOMIC_KIND has to be default integer. There's no
problem in the standard having multiple kinds with the same precision
(but different other characteristics as desired).
This is not nontrivial.
> It seems to me that we can fix this by putting a sentence in the
> description of argument ATOM in ATOMIC_DEFINE and ATOMIC_REF that it
> can not be a subobject of sequence type or a derived type with BIND
Totally unnecessary and horrible, just "do it right". If C/Posix can do
sig_atomic_t (and it can, and IBM can too) so can we (in this case the C
compiler is *not* at liberty to destroy the semantics). Let's not make
mountains out of imaginary molehills.
(And if the C compiler doesn't support sig_atomic_t then there won't be
a corresponding kind that interoperates, so there is no problem even
with non-conforming C compilers.)
.....................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3