(j3.2006) [ukfortran] (SC22WG5.4944) AW: Thoughts on Reinhold's thoughts

N.M. Maclaren nmm1
Sat Mar 30 05:41:32 EDT 2013


On Mar 29 2013, Bader, Reinhold wrote:
>> 
>> (B.1, B.4) CHANGE TEAM synchronization and ancestor-team addressing
>> 
>> Reinhold gave an example where image 1 cannot do things asynchronously
>> while the remaining images, decomposed into two teams, do something
>> else, because of the synchronization requirements of CHANGE TEAM.  If it
>> were possible to use ancestor-team coindexing (I haven't given much
>> thought to the syntax) one could decompose first into two teams, image 1
>> and the rest of them, then decompose the remaining teams:
>
> Unfortunately, item T2 of N1930 prohibits going outside the current team 
> via coindexing, and I think with good reason: It would violate 
> composability of the programming model. Of course, there still should be 
> some way of efficiently exchanging data between subteams, motivating my 
> desire to remove the big barrier around CHANGE TEAM (effectively saying: 
> If we can't pull data into a team from its inside, lets push them in from 
> the outside).

Slightly more on this.  My suggestion in my response addresses this in
several ways:

    FORM TEAMS would be a mere collective that returns a handle but does
no synchronisation
    CHANGE TEAMS would synchronise only the subteam, but would do so at
beginning and end
    There would be no problem about uninvolved subteams continuing with
other computation or in other subteams

'Outside' images could push data into the subteam, but it could not use
it, because there is no way to synchronise.  Well, actually, there is,
but I am in two minds about whether it is a facility or a loophole that
needs closing.

If 'outside' synchronises with 'inside' using consistent atomics and
SYNC MEMORY, should that be legal?  While I can't think of a solid
reason why not, I can think of a lot of consequences, and it won't just
happen in implementations (i.e. they will have to take steps to ensure
that it works).


Regards,
Nick.




More information about the J3 mailing list