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

[Bader, Reinhold]

Hello Nick, 

> -----Urspr?ngliche Nachricht-----
> Von: N.M. Maclaren [mailto:nmm1 at hermes.cam.ac.uk] Im Auftrag von N.M.
> Maclaren
> Gesendet: Samstag, 30. M?rz 2013 10:42
> An: Bader, Reinhold
> Cc: Van.Snyder at jpl.nasa.gov; fortran standards email list for J3; sc22wg5
> Betreff: Re: [ukfortran] (SC22WG5.4944) AW: (j3.2006) Thoughts on Reinhold's
> thoughts
> 
> 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

>From the "usability" point of view this already would be a big improvement. 

> 
> 'Outside' images could push data into the subteam, but it could not use
> it, because there is no way to synchronise.  

My data_feeder example effectively uses double buffering and separates 
buffer exchange (a pure memory operation) via a partial synchronization operation
in the ancestor team. 

> 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?  

If coindexing ancestor-inherited coarrays is possible. I believe it shouldn't be.

> 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.