(j3.2006) (SC22WG5.3746) [ukfortran] Atomic stuff

[Malcolm Cohen]

Jim Xia wrote:
>
>
> > Any vendor who allows those as extensions can do whatever they like 
> with
> > 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 
> attribute.
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.)

Cheers,
-- 
.....................Malcolm Cohen, Nihon NAG, Tokyo.