From owner-sc22wg5@open-std.org Wed Dec 3 18:46:56 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 3BEFBC56CF8; Wed, 3 Dec 2008 18:46:56 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by www2.open-std.org (Postfix) with ESMTP id 52AA5C4596D for ; Wed, 3 Dec 2008 18:46:54 +0100 (CET) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB3HkRNj017769 for ; Wed, 3 Dec 2008 12:46:27 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB3Hkrfw163846 for ; Wed, 3 Dec 2008 12:46:53 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB3Hkqnc015847 for ; Wed, 3 Dec 2008 12:46:53 -0500 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB3HkqlS015839; Wed, 3 Dec 2008 12:46:52 -0500 In-Reply-To: <20081203025222.12F4BC178E0@www2.open-std.org> References: <20081203025222.12F4BC178E0@www2.open-std.org> To: Van.Snyder@jpl.nasa.gov, fortran standards email list for J3 Cc: j3-bounces@j3-fortran.org, sc22wg5 MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.3701) Atomic stuff X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Jim Xia Date: Wed, 3 Dec 2008 12:46:49 -0500 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 12/03/2008 12:46:51, Serialize complete at 12/03/2008 12:46:51 Content-Type: multipart/alternative; boundary="=_alternative 0061ABE185257514_=" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 0061ABE185257514_= Content-Type: text/plain; charset="US-ASCII" 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 integer(2) x(3) integer(ATOMIC_INTEGER_KIND) y, z equivalence (y, x(2)) equivalence (z, x) 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. Thanks, Jim Xia RL Fortran Compiler Test IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 Phone (905) 413-3444 Tie-line 313-3444 email: jimxia@ca.ibm.com D2/YF7/8200 /MKM From: Van Snyder To: sc22wg5 Date: 12/02/2008 09:52 PM Subject: (j3.2006) (SC22WG5.3701) Atomic stuff I wasn't entirely satisfied with the way we provided for atomic memory operations in Tokyo, but I wanted to think about it some more before bringing it up. I can think of three ways that I would prefer to the intrinsic subroutines described in 08-297r1. 1. Provide an attribute for a variable that says accesses to it are atomic. This seems to have been the intent of the use of VOLATILE in 08-007r2:Note 8.28. One might desire to enclose the declaration and access within a BLOCK, so the attribute would work like ASYNCHRONOUS in that respect: a declaration of the attribute within a BLOCK isn't a declaration of a new variable. So the spin loop in Note 8.38 becomes use, intrinsic :: ISO_FORTRAN_ENV, only: Atomic_logical_kind logical(atomic_logical_kind) :: LOCKED[*] = .true. integer :: P, Q BLOCK atomic :: LOCKED if ( this_image() == p ) then sync memory locked[q] = .false. sync memory else do while ( locked ); end do end if end BLOCK Notice no VAL variable is needed. 2. Use the function/updater syntax I've been advocating for more than twenty years. Suppose an intrinsic function/updater pair are called ATOMIC. Assume they have SYNC MEMORY in them as needed. Then the spin loop in Note 8.38 becomes use, intrinsic :: ISO_FORTRAN_ENV, only: Atomic_logical_kind logical(atomic_logical_kind) :: LOCKED[*] = .true. integer :: P, Q if ( this_image() == p ) then atomic(locked[q]) = .false. else do while ( atomic(locked) ); end do end if 3. Define type-bound function/updater pairs, named, say ATOMIC, as we did for access to complex parts. Again, the function and/or updater are assumed to have SYNC MEMORY in them as needed. Then the spin loop in Note 8.38 becomes use, intrinsic :: ISO_FORTRAN_ENV, only: Atomic_logical_kind logical(atomic_logical_kind) :: LOCKED[*] = .true. integer :: P, Q if ( this_image() == p ) then locked[q]%atomic = .false. else do while ( locked%atomic ); end do end if I prefer any of these to 08-297r1. Each of these could be specified to be available only for variables of specified type and kind, just as for the intrinsic subroutines in 08-297r1. The last two require careful definition in the case an atomic thing-o is an actual argument: Are copy semantics used, or is ATOMIC a thunk? Whether a thunk or copy could depend upon an attribute of the corresponding dummy argument, say ACTIVE. Saying so with a dummy argument attribute would be useful in other contexts as well. Other cases, such as appearing in an I/O list, are obvious in all three methods, and impossible with the intrinsic subroutine method. Actually, I would prefer a much higher level concept, similar to an Ada protected variable (once again I urge you to consult "Concurrent and Real-Time Programming in Ada" by Andy Wellings and Alan Burns). These let you customize your synchronization strategy just as much as atomic references do, but it's much less likely you'll botch things. These would have to be thunks. -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, the President, or anybody else. _______________________________________________ J3 mailing list J3@j3-fortran.org http://j3-fortran.org/mailman/listinfo/j3 --=_alternative 0061ABE185257514_= Content-Type: text/html; charset="US-ASCII"
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


    integer(2) x(3)
    integer(ATOMIC_INTEGER_KIND) y, z

    equivalence (y, x(2))
    equivalence (z, x)

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.

Thanks,


Jim Xia

RL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia@ca.ibm.com
D2/YF7/8200 /MKM


From: Van Snyder <Van.Snyder@jpl.nasa.gov>
To: sc22wg5 <sc22wg5@open-std.org>
Date: 12/02/2008 09:52 PM
Subject: (j3.2006) (SC22WG5.3701) Atomic stuff




I wasn't entirely satisfied with the way we provided for atomic memory
operations in Tokyo, but I wanted to think about it some more before
bringing it up.

I can think of three ways that I would prefer to the intrinsic
subroutines described in 08-297r1.

1.  Provide an attribute for a variable that says accesses to it are
atomic.  This seems to have been the intent of the use of VOLATILE in
08-007r2:Note 8.28.  One might desire to enclose the declaration and
access within a BLOCK, so the attribute would work like ASYNCHRONOUS in
that respect: a declaration of the attribute within a BLOCK isn't a
declaration of a new variable.  So the spin loop in Note 8.38 becomes

       use, intrinsic :: ISO_FORTRAN_ENV, only: Atomic_logical_kind
       logical(atomic_logical_kind) :: LOCKED[*] = .true.
       integer :: P, Q
       BLOCK
         atomic :: LOCKED
         if ( this_image() == p ) then
           sync memory
           locked[q] = .false.
           sync memory
         else
           do while ( locked ); end do
         end if
       end BLOCK

Notice no VAL variable is needed.

2.  Use the function/updater syntax I've been advocating for more than
twenty years.  Suppose an intrinsic function/updater pair are called
ATOMIC.  Assume they have SYNC MEMORY in them as needed.  Then the spin
loop in Note 8.38 becomes

       use, intrinsic :: ISO_FORTRAN_ENV, only: Atomic_logical_kind
       logical(atomic_logical_kind) :: LOCKED[*] = .true.
       integer :: P, Q
       if ( this_image() == p ) then
         atomic(locked[q]) = .false.
       else
         do while ( atomic(locked) ); end do
       end if

3.  Define type-bound function/updater pairs, named, say ATOMIC, as we
did for access to complex parts.  Again, the function and/or updater are
assumed to have SYNC MEMORY in them as needed.  Then the spin loop in
Note 8.38 becomes

       use, intrinsic :: ISO_FORTRAN_ENV, only: Atomic_logical_kind
       logical(atomic_logical_kind) :: LOCKED[*] = .true.
       integer :: P, Q
       if ( this_image() == p ) then
         locked[q]%atomic = .false.
       else
         do while ( locked%atomic ); end do
       end if

I prefer any of these to 08-297r1.

Each of these could be specified to be available only for variables of
specified type and kind, just as for the intrinsic subroutines in
08-297r1.

The last two require careful definition in the case an atomic thing-o is
an actual argument: Are copy semantics used, or is ATOMIC a thunk?
Whether a thunk or copy could depend upon an attribute of the
corresponding dummy argument, say ACTIVE.  Saying so with a dummy
argument attribute would be useful in other contexts as well.

Other cases, such as appearing in an I/O list, are obvious in all three
methods, and impossible with the intrinsic subroutine method.

Actually, I would prefer a much higher level concept, similar to an Ada
protected variable (once again I urge you to consult "Concurrent and
Real-Time Programming in Ada" by Andy Wellings and Alan Burns).  These
let you customize your synchronization strategy just as much as atomic
references do, but it's much less likely you'll botch things.  These
would have to be thunks.

--
Van Snyder                    |  What fraction of Americans believe
Van.Snyder@jpl.nasa.gov       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.

_______________________________________________
J3 mailing list
J3@j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3

--=_alternative 0061ABE185257514_=--