gmegan / specification

OpenSHMEM Application Programming Interface
http://www.openshmem.org
1 stars 0 forks source link

Team-based collective interaction with deprecated active-set collectives #160

Open naveen-rn opened 4 years ago

naveen-rn commented 4 years ago

https://github.com/openshmem-org/specification/issues/303

naveen-rn commented 4 years ago

Is this a valid code? Can we concurrently use an active-thread based collective and a team-based collective inside a parallel region?

#pragma omp parallel num_threads(2)
{
    if (omp_get_thread_num() == 0) {
        shmem_team_barrier(SHMEM_TEAM_WORLD);
    } else if (omp_get_thread_num() == 1) {
        shmem_barrier_all();
    }
}
nspark commented 4 years ago

I think this is undefined behavior. My rationale is that shmem_team_barrier includes the following note:

The shmem_barrier_all routine is equivalent to calling shmem_ctx_quiet on the default context followed by calling shmem_team_sync on the default team.

Because of this equivalence, I think your code example is undefined due to the concurrent use of the default/world team.

That said, because there's no explicit connection between active-set collectives and team collectives, I think the following code should have well-defined behavior (assuming proper initialization of the pSync array):

#pragma omp parallel num_threads(2)
{
    if (omp_get_thread_num() == 0) {
        shmem_team_barrier(SHMEM_TEAM_WORLD);
    } else if (omp_get_thread_num() == 1) {
        shmem_barrier(0, 0, shmem_n_pes(), pSync);
    }
}
naveen-rn commented 4 years ago

I understand your rationale - this makes sense.

FWIU, as an implementer - we should make sure that both the active-set and team-based collectives are completely independent of each other inside the runtime to avoid any undefined behaviour.

PS: Both our examples should have been with sync rather than barrier (I suppose there is no team barrier).