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

[Van Snyder]

N.M. Maclaren wrote:
> On Dec 4 2008, Van Snyder wrote:
>   
>> 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.  ...
>>     
>
> Regrettably, that is NOT true!
>
> There are virtually no systems that support atomic access to unaligned
> objects, and many compilers that allow ordinary objects to be unaligned.
> There used to be many systems where atomic accesses had to be to a
> particular size, which was not necessarily the size of any of Fortran's
> default types, and there may still be some.
>
> If you make ATOMIC simply an attribute, and allow it to be different in
> different scopes, all such systems would have to implement atomic accesses
> using locking, or risk the race condition.  Given that benchmarketing rules,
> what do YOU think they will do?
>   

How is this problem solved by the atomic subroutines from 186?  There's 
nothing in 08-297r1 that requires the arguments to be on alignment 
boundaries.

It depends upon which types and kinds are allowed to have the ATOMIC 
attribute.  Then it depends upon what optimizers can do without help 
from the linker and loader.  Then it depends upon what decisions they're 
allowed to make at run time.

Otherwise, ATOMIC would have to be an attribute on the declaration of 
the object, and couldn't be added after the declaration in some 
constructs or scoping units.  Nonatomic dummy arguments could correspond 
to atomic actual arguments, but not vice versa.  This is still better 
than adding two intrinsics that almost everybody will have to look up 
before using them.  I still have to look up INDEX, after 30 years.

Anyway, after working out the details, I like my second proposal 
better.  That is, an intrinsic accessor, spelt %ATOMIC, bound to 
specified types and kinds, i.e. INTEGER(ATOMIC_INT_KIND) and 
LOGICAL(ATOMIC_LOGICAL_KIND).

> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service,
> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> Email:  nmm1 at cam.ac.uk
> Tel.:  +44 1223 334761    Fax:  +44 1223 334679
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20081204/1d825b35/attachment.html