team_id::when_here()
@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:
-
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). -
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?
Comments (9)
-
-
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. -
reporter - changed milestone to 2019.03.31 release
Current plan is I will document this as unimplemented for the 2018.9.0 release, to be addressed next release.
-
reporter - changed milestone to 2019.09.30 release
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)
-
reporter -
assigned issue to
Proposed solution in pull request #106
-
assigned issue to
-
reporter - changed status to resolved
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>>
-
reporter 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>>
-
reporter Merge pull request #106 into develop
- issue170-team-whenhere:
update ChangeLog
Add issue170 test
fix issue
#170: Implement team::when_here()
→ <<cset 4aa3a71a93f1>>
- issue170-team-whenhere:
update ChangeLog
Add issue170 test
fix issue
-
reporter fixup: fix issue
#170: Implement team::when_here()Adopt a simpler and more stable implementation, suggested by John.
→ <<cset b5dfa82a36d9>>
- Log in to comment
I am in complete agreement.