<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
N.M. Maclaren wrote:
<blockquote cite="mid:20081204091023.4E816CA5FE4@www2.open-std.org"
type="cite">
<pre wrap="">On Dec 4 2008, Van Snyder wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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. ...
</pre>
</blockquote>
<pre wrap=""><!---->
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?
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
<blockquote cite="mid:20081204091023.4E816CA5FE4@www2.open-std.org"
type="cite">
<pre wrap="">
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: <a class="moz-txt-link-abbreviated" href="mailto:nmm1@cam.ac.uk">nmm1@cam.ac.uk</a>
Tel.: +44 1223 334761 Fax: +44 1223 334679
_______________________________________________
J3 mailing list
<a class="moz-txt-link-abbreviated" href="mailto:J3@j3-fortran.org">J3@j3-fortran.org</a>
<a class="moz-txt-link-freetext" href="http://j3-fortran.org/mailman/listinfo/j3">http://j3-fortran.org/mailman/listinfo/j3</a>
</pre>
</blockquote>
<br>
</body>
</html>