SC/collectives: add change logs #10
Conversation
minsii
force-pushed
the
pr/sc/collectives/changelogs
branch
from
3f7db5d to
d96591c
Compare
|
This PR contains several fixes and change logs for the collective section. @nspark @jdinan @davidozog Please review. |
content/shmem_sync_all.tex
Outdated
| @@ -1,6 +1,6 @@ | |||
| \apisummary{ | |||
| Registers the arrival of a \ac{PE} at a synchronization point and suspends | |||
| execution until all other \acp{PE} in the default team arrive at a synchronization point. For multithreaded programs, execution is suspended | |||
| execution until all other \acp{PE} in the default team arrive at the synchronization point. For multithreaded programs, execution is suspended | |||
There was a problem hiding this comment.
Can we replace "default team" with SHMEM_TEAM_WORLD or "world team"?
There was a problem hiding this comment.
"default team" is used in several sections including teams, collectives, and memory management. It is defined in section 7. Library Handles.
I agree that SHMEM_TEAM_WORLD is more specific. Perhaps we want to replace it everywhere for consistency. Do we need to create separate commits for each SC? Is there a way that we can fix it in a single commit?
There was a problem hiding this comment.
I'd prefer "world team"—since, as with contexts, one could copy the handle to SHMEM_TEAM_WORLD and still refer to the same team—but this would be a "whole document" change (which I'd support).
There was a problem hiding this comment.
Good point on "world team". I created issue openshmem-org#371 to track the changes. I'd deal with the updates in separate commits and submit to the corresponding SC.
There was a problem hiding this comment.
@nspark I'm fine with "world team" but we need to be precise about what that means. If one thread is calling shmem_malloc, is it a violation of the threading rules for another to call shmem_team_barrier(SHMEM_TEAM_WORLD) at the same time?
There was a problem hiding this comment.
Thinking again about the example @nspark mentioned: one does handle = SHMEM_TEAM_WORLD; and uses handle in later calls. The value of handle is still the predefined SHMEM_TEAM_WORLD, and the function call reads the value but not &handle. Thus, I don't think people may confuse if the handle is a different team.
However, if we say "world team", I am afraid that people may confuse if a duplicated team of SHMEM_TEAM_WORLD (e.g., created by shmem_team_split_strided) is also a "world team".
In summary, I am now thinking SHMEM_TEAM_WORLD might be a better replacement for "default team." Does it resolve @jdinan's question, or avoid such confusion?
There was a problem hiding this comment.
In Section 7, you can clarify that SHMEM_TEAM_WORLD handle corresponds to the "world team". Currently it says:
Handle of type shmem_team_t that corresponds to the default team of all PEs in the OpenSHMEM program.
There was a problem hiding this comment.
I am working on the default team->world team replacement now. It will be in separate PRs.
minsii
force-pushed
the
pr/sc/collectives/changelogs
branch
from
d96591c to
eed3e45
Compare
The reduction operators mentioned in the intro of active-set-based collectives did not follow a specific order, i.e., neither alphabetized nor grouped by operator types. This patch reorders it to match the description of team-based collectives. The new order also matches that of the operator definitions in section 9.11.7 SHMEM_REDUCTIONS.
minsii
force-pushed
the
pr/sc/collectives/changelogs
branch
from
eed3e45 to
55d39c4
Compare
|
@nspark @jdinan @davidozog I think all comments should be fixed except the "default team"->"world team" replacement. I will address it in separate PRs. This PR should be ready for review & merge. Could you please check again? |
Minor formatting tweaks
Minor rewording, as team-based broadcasts are new, so we're not changing behavior, but it's worth calling out here that the behavior is different from that of active-set-based broadcasts.
Replace default team with world team
No description provided.