Specify persona::active_with_caller()

[Dan Bonachea]

Background

Many of the UPC++ API calls (notably including all collective operations) require the calling thread to be holding the master persona. Also, the master persona is the only one that ever runs incoming RPCs and remote completions.

Problem

There is currently no way via the API to query the status of this critical master-ness property. We don't even provide a means to compare personas for equality. This creates a modularity problem with libraries layered atop UPC++, because they have no way to query the master status of a given thread, in order to control RPC progression or enforce their own invariants on the master-persona status of calls from their own clients.

Even in a monolithic threaded program with a "flat" threading design, it's annoying that one needs to manually track which thread is holding the master persona, when UPC++ already has to track this information and could easily expose it.

The following two complementary proposals are meant to help alleviate such difficulties.

Proposal 1:

bool upcxx::have_master_persona();

Semantics:
Returns true if and only if the master persona is in the active persona stack of the calling thread.

UPC++ progress level: none

Proposal 2:

Add EqualityComparable to upcxx::persona

operator==(const upcxx::persona& lhs, const upcxx::persona& rhs);
operator!=(const upcxx::persona& lhs, const upcxx::persona& rhs);

Semantics:
These operators return true if and only if the two provided personas are the same (or different, respectively) persona.

UPC++ progress level: none

[Paul Hargrove]

I can clearly see the value to both proposals and the implementations cannot possibly be difficult.

[john bachan]

Proposal 1 is already implemented more generally as bool persona::active_with_caller(), where it returns true if the calling OS thread owns this persona. Use master as this and there you go. Shall we spec active_with_caller?

Proposal 2 is unnecessary since persona's are not copyable, ie two different persona objects can never be the "same". What you want to do is just compare persona addresses, which are just pointers and already covered by the builtin bool operator==(T*,T*)

[Dan Bonachea]

I agree that bool persona::active_with_caller() is more general than Proposal 1, and am fine with speccing that instead.

Proposal 2 is unnecessary since persona's are not copyable, [...] What you want to do is just compare persona addresses

What you are saying is that we DO have a semantic concept of persona equality (ie identity), but we are refusing to expose an actual equality operator implementing and directly exposing that semantic. This seems like a design mistake to me. In particular, it means that classes containing a persona & field cannot use defaulted comparison. It also artifically prevents use of persona in any other context requiring EqualityComparable, even though this type has a semantic concept of identity and equality.

Is there any reason not to just expose the admittedly trivial comparison:

operator==(const upcxx::persona& lhs, const upcxx::persona& rhs) { return &lhs == &rhs }
operator!=(const upcxx::persona& lhs, const upcxx::persona& rhs) { return !(lhs == rhs) }

[Dan Bonachea]

Proposed solution 1 now in pull request #23.

Amir and John have convinced me not to pursue EqualityComparable at this time.

[Dan Bonachea]

issue #142: Specify persona::active_with_caller()

Resolves issue #142

→ <<cset 9540fa061fbf>>