[Coarray-ts] Teams

John Reid John.Reid at stfc.ac.uk
Wed May 30 11:16:10 EDT 2012

N.M. Maclaren wrote:
> On May 29 2012, Bill Long wrote:
>> I've been "shopping" these new team ideas with users and got strong
>> feedback that two, different, concepts are desirable in different
>> situations. Perhaps we need to support both.
>> 1) A system for partitioning the current set of all images into
>> subsets that are similar to the scheme currently under discussion. All
>> cosubscripts would be relative to the new partition containing the
>> local image, etc. This is particularly attractive for writing a
>> library routine that can be called collectively by the images in the
>> partition.
> I.e. just like MPI subset communicators. Yes.
>> It also addresses the "climate model" problem. The one irritant is how
>> to (or whether to allow) access to images in a different partition.
> Put those the other way round! How would such accesses be synchronised?
> We need to decide a synchronisation model as part of deciding whether
> to allow such accesses.

I thought of this and it is included here:

T2b: While an image executes a statement it shall be a full member of
     one and only one team, but also have access through new syntax to
     the data and synchronization features of its ancestor teams.

>> 2) A system for creating a team similar to the original proposal. This
>> creates teams with names, but keeps the current cosubscripts and image
>> set. The teams are used for SYNC TEAM and as arguments to collectives.
>> This intent is that these teams are fairly small, such as the images
>> in the local SMP domain, or the list of images along boundaries of an
>> array. The main goal of these teams is better performance.
> Right, but the consequence of this is that synchronisation of any
> image outside the team - and any memory on any of those images - or
> any memory on those images accessed from outside the team - is
> synchronised only at the next global SYNC ALL. Not nice.

The other, more selective, synchronisation features would still be 

>> On 5/29/12 10:20 AM, John Reid wrote:
>>> There is an issue with allocatable arrays that are allocated within a
>>> team. Can these be supported in symmetric memory or are they are like
>>> allocatable components of a coarray? They can be supported in memory
>>> that is symmetric for the team provided they are all deallocated when
>>> execution reverts to the parent team. So we have two alternative
>>> requirements
>>> T7a. It should be possible to support allocatable arrays that are
>>> allocated within a team in memory that is symmetric for the team.
>>> T7b. It need not be possible to support allocatable arrays that are
>>> allocated within a team in memory that is symmetric for the team.
>> This is a non-issue for type 2 "teams".
> I don't follow. If you can allocate within such a team, you have
> even worse synchronisation issues than for data accesses, because
> the allocation status can become inconsistent across the program.

No, there is no team allocation in this model.
>> For type 1 "partitions", I think we have to keep T7a for the model to
>> make sense. A subprogram in a stand alone program with no partitions
>> looks the same as one called from a partition to the user. The
>> requirement needed for this to work is that if the partition set is
>> dissolved and you revert to the parent, then any allocations made by
>> each of the partitions need to be deallocated at the point where the
>> partition is dissolved. That way the symmetric heap returns to the
>> state it had when the previous partition occurred, and should still be
>> symmetric.

I think the model since "makes sense" under T7b. It is just that on 
hardware that can take advantage of symmetric memory, there will be a 
loss of performance.



More information about the Coarray-ts mailing list