<br><font size=2 face="sans-serif">Now I take another look at the atomic
stuff we worked out in Tokyo, I think there is an issue we didn't address:
alignment. Consider on a system we have atomic_integer_kind being
4 bytes, and the processor also supports 2 byte integers, then the following
declarations</font>
<br>
<br>
<br><font size=2 face="sans-serif"> integer(2) x(3)</font>
<br><font size=2 face="sans-serif"> integer(ATOMIC_INTEGER_KIND)
y, z</font>
<br>
<br><font size=2 face="sans-serif"> equivalence (y, x(2))</font>
<br><font size=2 face="sans-serif"> equivalence (z, x)</font>
<br>
<br><font size=2 face="sans-serif">Now either y or z is out of natural
alignment. This will certainly cause implementation problems on atomic
operations on y and z. We have to disallow this to happen.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br>
<br><font size=2 face="sans-serif">Jim Xia<br>
<br>
RL Fortran Compiler Test<br>
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7<br>
Phone (905) 413-3444 Tie-line 313-3444<br>
email: jimxia@ca.ibm.com<br>
D2/YF7/8200 /MKM</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Van Snyder <Van.Snyder@jpl.nasa.gov></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">sc22wg5 <sc22wg5@open-std.org></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">12/02/2008 09:52 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">(j3.2006) (SC22WG5.3701) Atomic stuff</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>I wasn't entirely satisfied with the way we provided
for atomic memory<br>
operations in Tokyo, but I wanted to think about it some more before<br>
bringing it up.<br>
<br>
I can think of three ways that I would prefer to the intrinsic<br>
subroutines described in 08-297r1.<br>
<br>
1. Provide an attribute for a variable that says accesses to it are<br>
atomic. This seems to have been the intent of the use of VOLATILE
in<br>
08-007r2:Note 8.28. One might desire to enclose the declaration and<br>
access within a BLOCK, so the attribute would work like ASYNCHRONOUS in<br>
that respect: a declaration of the attribute within a BLOCK isn't a<br>
declaration of a new variable. So the spin loop in Note 8.38 becomes<br>
<br>
use, intrinsic :: ISO_FORTRAN_ENV, only: Atomic_logical_kind<br>
logical(atomic_logical_kind) :: LOCKED[*] =
.true.<br>
integer :: P, Q<br>
BLOCK<br>
atomic :: LOCKED<br>
if ( this_image() == p ) then<br>
sync memory<br>
locked[q] = .false.<br>
sync memory<br>
else<br>
do while ( locked ); end do<br>
end if<br>
end BLOCK<br>
<br>
Notice no VAL variable is needed.<br>
<br>
2. Use the function/updater syntax I've been advocating for more
than<br>
twenty years. Suppose an intrinsic function/updater pair are called<br>
ATOMIC. Assume they have SYNC MEMORY in them as needed. Then
the spin<br>
loop in Note 8.38 becomes<br>
<br>
use, intrinsic :: ISO_FORTRAN_ENV, only: Atomic_logical_kind<br>
logical(atomic_logical_kind) :: LOCKED[*] =
.true.<br>
integer :: P, Q<br>
if ( this_image() == p ) then<br>
atomic(locked[q]) = .false.<br>
else<br>
do while ( atomic(locked) ); end do<br>
end if<br>
<br>
3. Define type-bound function/updater pairs, named, say ATOMIC, as
we<br>
did for access to complex parts. Again, the function and/or updater
are<br>
assumed to have SYNC MEMORY in them as needed. Then the spin loop
in<br>
Note 8.38 becomes<br>
<br>
use, intrinsic :: ISO_FORTRAN_ENV, only: Atomic_logical_kind<br>
logical(atomic_logical_kind) :: LOCKED[*] =
.true.<br>
integer :: P, Q<br>
if ( this_image() == p ) then<br>
locked[q]%atomic = .false.<br>
else<br>
do while ( locked%atomic ); end do<br>
end if<br>
<br>
I prefer any of these to 08-297r1.<br>
<br>
Each of these could be specified to be available only for variables of<br>
specified type and kind, just as for the intrinsic subroutines in<br>
08-297r1.<br>
<br>
The last two require careful definition in the case an atomic thing-o is<br>
an actual argument: Are copy semantics used, or is ATOMIC a thunk?<br>
Whether a thunk or copy could depend upon an attribute of the<br>
corresponding dummy argument, say ACTIVE. Saying so with a dummy<br>
argument attribute would be useful in other contexts as well.<br>
<br>
Other cases, such as appearing in an I/O list, are obvious in all three<br>
methods, and impossible with the intrinsic subroutine method.<br>
<br>
Actually, I would prefer a much higher level concept, similar to an Ada<br>
protected variable (once again I urge you to consult "Concurrent and<br>
Real-Time Programming in Ada" by Andy Wellings and Alan Burns). These<br>
let you customize your synchronization strategy just as much as atomic<br>
references do, but it's much less likely you'll botch things. These<br>
would have to be thunks.<br>
<br>
-- <br>
Van Snyder
| What fraction of Americans believe <br>
Van.Snyder@jpl.nasa.gov | Wrestling is real
and NASA is fake?<br>
Any alleged opinions are my own and have not been approved or<br>
disapproved by JPL, CalTech, NASA, the President, or anybody else.<br>
<br>
_______________________________________________<br>
J3 mailing list<br>
J3@j3-fortran.org<br>
</font></tt><a href="http://j3-fortran.org/mailman/listinfo/j3"><tt><font size=2>http://j3-fortran.org/mailman/listinfo/j3</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>