(j3.2006) Integration of co-arrays with the intrinsic shift functions

Craig Rasmussen crasmussen
Tue Jul 17 13:30:03 EDT 2007

On Jul 17, 2007, at 8:21 AM, dick.hendrickson at att.net wrote:

> -------------- Original message ----------------------
> From: Aleksandar Donev <donev1 at llnl.gov>
>> Craig,
>>> We should actually
>>> integrate co-arrays into the Fortran language and define SUM so that
>>> it takes a co-array as an arguments.
>> SUM already takes co-arrays as arguments. Co-arrays when  
>> referenced on the
>> image in question are just like normal arrays. You'll have to come  
>> up with
>> something more specific than this. Just make sure you don't break  
>> generic
>> resolution for SUM or break the old serial SUM along the way.  
>> Also, SUM is a
>> function, and so now we would have an intrinsic function with side- 
>> effects
>> (synchronization).
> No, I don't think we can or should move the sync into the  
> functions.  On
> heterogeneous processors the order of evaluation can be different on
> different images.  So, Craig's example expression
>      x = co_shift(A,+1)) + co_shift(A,-1)) ! or whatever
> might be doing a sync for the first shift on some images and the
> second on others.  Isn't this a recipe for deadlock?

All of the synchronization occurs in the runtime which can easily  
figure out the element-wise synchronization dependencies.  Imagine  
the compiler completely unrolling all of the implicit loops.  The  
individual statements can be executed in any order (think DO  
CONCURRENT).  I don't see any deadlock issues?

(The heterogeneous architecture I've been referring to is multiple  
heterogeneous processing units on one image.)

> Even worse, I think an image can be a member of more than one team.
> If so, then something like
>      x = co_shift(A,+1,teamA)) + co_shift(A,-1,teamB))
> surely can't work if an image is a member of both teams and the  
> compilers
> do different ordering of operations.

I must not understand the issue with ordering.  However, teams  
wouldn't be allowed with data-parallel operations that must occur  
over the entire array (or mask of an array).

> If we're going to make the collective routines into functions, then I
> think we have to fall back on the general rule that you can't  
> reference
> an off-image element unless you've done the proper syncs.  That makes
> the use of collective functions error-prone.  Better to make them into
> subroutines with syncs.

Again, I don't understand.  Could you provide an example?  Collective  
functions would return a temporary object and the operation (sum)  
can't continue until the temporaries are in place.  Of course the  
user would be required to use syncs to make sure that A is ready (as  
before).  I think the key is that there are no side effect on A in  


More information about the J3 mailing list