team_id::when_here()

[Dan Bonachea]

@jdbachan wrote:

team_id::when_here() isn't in the implementation (and shouldn't be in the spec?) because our only way to create new teams has barrier semantics, thus making it impossible to be holding a team_id that doesn't already exist everywhere.

My response -Two observations:

1. team.split is currently the only way to create a new team. However we expect to add additional team constructors in the future that don't necessarily imply barrier semantics (in fact, that's one of the main benefits of an additive constructor).

2. The semantics of split only ensure that all ranks (in the parent) have reached the call before any can leave. It does not (currently) guarantee that none can leave the call until all have constructed the local representative object of the team. So unless we strengthen this, it's conceivable for a member of a new team to leave the split and send an RPC containing a team/id to a member who is still running user progress inside split (but before having fully constructed the new local team object).

I agree the second probably can't happen in the current implementation, so for now I propose we implement team_id::when_here() as trivially equivalent to make_future(team_id::here())

However for the purposes of this release, we can easily document this method as unimplemented without losing anything important.

Thoughts?

[john bachan]

I am in complete agreement.

[Paul Hargrove]

There are definitely scenarios that could provide a future team constructor w/o barrier semantics.

Dan and I have discussed the usefulness of GEX team constructors which would operate on "computable" splits. For instance, even/odd or "my row" can be expressed compactly (similar to strided APIs) and such that no communication is required for any rank to know the ranks of all members of the team in which it will be a member. Since the teamid in GEX is currently selected by rank=0 in the new team, the only communication required would be a broadcast, which is less than barrier semantics. If GEX used something like a SHA-hash to generate its teamids, then this sort of team constructor might even be communication-free.

I see no problem with leaving when_here out of the implementation in this release if others agree.
However, we need to agree if it is to remain in the spec or not.

[Dan Bonachea]

Current plan is I will document this as unimplemented for the 2018.9.0 release, to be addressed next release.

[Dan Bonachea]

This issue was triaged at the 2019-07-24 Pagoda issue meeting and assigned a new milestone.

John thinks he can provide this trivially for this release (IF time available)

[Dan Bonachea]

Proposed solution in pull request #106

[Dan Bonachea]

fix issue #170: Implement team::when_here()

For now this is just sugar for make_future(this.here()), since that is guaranteed to be correct with the current team constructors (specifically, the fact that RPCs containing a team_id can only execute on the master persona which is guaranteed to have passed the entry barrier on team::split()).

Resolves issue #170

→ <<cset 1ad4a2f19168>>

[Dan Bonachea]

fix issue #170: Implement team::when_here()

For now this is just sugar for make_future(this.here()), since that is guaranteed to be correct with the current team constructors (specifically, the fact that RPCs containing a team_id can only execute on the master persona which is guaranteed to have passed the entry barrier on team::split()).

Resolves issue #170

→ <<cset 1ad4a2f19168>>

[Dan Bonachea]

Merge pull request #106 into develop

• issue170-team-whenhere: update ChangeLog Add issue170 test fix issue #170: Implement team::when_here()

→ <<cset 4aa3a71a93f1>>

[Dan Bonachea]

fixup: fix issue #170: Implement team::when_here()

Adopt a simpler and more stable implementation, suggested by John.

→ <<cset b5dfa82a36d9>>