Decide on new upcxx::broadcast signature

[Dan Bonachea]

There's been alot of informal discussion about fundamentally changing the signature of upcxx::broadcast from the way it appears in the current spec draft. There's also at least one fundamental semantic problem with the current signature (issue #69).

Amir recently presented some slides which silently make the assumption the broadcast signature has already been changed, and the current draft of the programmer's guide also make this assumption but with a different signature.

I'm strongly in favor of changing the signature currently in the spec, but strongly opposed to the current chaos of every team member assuming a different solution.

We need to reach a consensus about this ASAP and nail down spec language for what we are releasing on Sept 30, otherwise there's a danger the spec, guide, tutorial materials and implementation could all disagree.

[Amir Kamil]

I suggested two overloads. one value-based and one buffer-based. Here are future-based definitions that are modeled after MPI_Bcast():

template<typename T>
future<T> broadcast(T &&value, intrank_t sender, team &team = world());

template<typename T>
future<> broadcast(T *buffer, std::size_t count,
                   intrank_t sender, team &team = world());

The sender's future would be made ready at the next user-level progress.

[Dan Bonachea]

Amir's proposed signatures make sense to me. I'd like to see a formal semantic description.

Presumably sender, team and count (for the second overload) are all single-valued and other arguments are not. Readying of the sender's future would imply source completion of the input, and future readying on non-senders would indicate operation completion with respect to that rank's destination buffer (only). Synchronization and memory ordering semantics would look similar to the current ones, but merged into one function.

[Dan Bonachea]

On the 8-22 Pagoda call we resolved to adopt Amir's proposed broadcast signatures, with synchronization semantics along the lines described in my previous comment (essentially IN_MYSYNC|OUT_MYSYNC semantics in UPC parlance, which is equivalent to MPI's broadcast synchronization semantics).

Amir agreed to draft the actual spec text, and the guide examples have already been updated accordingly.

[Amir Kamil]

Draft wording added in commit 3ac948b.

[Dan Bonachea]

New text looks great to me - thanks Amir!