Adjust ~dist_object() wording

[Dan Bonachea]

Current semantics for dist_object <T>::˜dist_object() begins:

If this instance is the same as the one constructed by the user, or one produced via a chain of moves from that instance, then this will destroy the current rank’s member of the distributed object.

First a minor quibble, the "user" technically doesn't construct anything, he writes code that calls allocators or constructors that may effect the construction of a dist_object.

But more generally, I don't understand why this statement begins with "If" and then lists the only two possibilities as "or", making the conditional vacuously satisfied. Is there another case I'm not seeing which does NOT satisfy this if conditional?

I would have fixed this wording myself, but I don't understand what it was originally intended to convey.

[Amir Kamil]

I agree that the wording can be better. I think the intent was to specify that destroying a dist_object that is the source of a move has no effect:

{
  dist_object<int> d1;
  {
    dist_object<int> d2 = std::move(d1); // move d1 into d2; d1 now invalid
  } // d2 destructed
} // d1 destructed, which does nothing

[Dan Bonachea]

intent was to specify that destroying a dist_object that is the source of a move has no effect

Makes sense, but we should probably state that explicitly, rather leaving at as the confusingly unspecified "else" to the if statement.

Related question: Don't we need to provide a move constructor for dist_object? Based on C++11 rules it sounds like we don't get a compiler-generated one because of the explicit destructor. Also, the move constructor preconditions should probably clarify whether the move performed in your example requires the master persona (as with the true constructors).

Same question for move constructor on persona_scope

[Amir Kamil]

Unless something needs to be clarified about the semantics, I think it's sufficient to specify that they are MoveConstructible.

I see no reason for the move constructor to require the master persona, as it wouldn't do any communication or anything else that requires access to a persona.

[Dan Bonachea]

Unless something needs to be clarified about the semantics, I think it's sufficient to specify that they are MoveConstructible.

I can think of enough semantic questions regarding the move constructor that it seems worth explicitly clarifying. Here's another: the normal constructor must be called collectively across the team, does the move constructor require a collective call? (hopefully not)

I see no reason for the move constructor to require the master persona, as it wouldn't do any communication or anything else that requires access to a persona.

I guess the question is really about what thread-safety guarantees are provided by the implementation of a mutable dist_object container. It particular, what happens if an RPC arrives on the master persona and accesses a dist_object while another persona is simultaneously moving that dist_object (the container, not the contained value). This is potentially problematic because the dist_id->dist_object conversion takes place inside the library before the RPC is invoked, so the client might not have a convenient mechanism to synchronize that conflict.

[Amir Kamil]

That's a good point. Since the dist_id->dist_object translation produces a reference, it would be problematic if a move happened concurrently with the translation. So the move constructor should require the master persona.

[Amir Kamil]

Along the same lines, a move of a persona should require that the persona not be active on any thread's stack, and that no LPC's are concurrently queued on the persona while it is being moved. Otherwise we have the same issues with stale references.

[Dan Bonachea]

a move of a persona should require

Personas are not moveable, and I don't recall discussing anything to allow that.

persona_scopes are moveable, but those are inherently single-threaded objects and do not contain LPCs.

[Amir Kamil]

You're right, I was conflating the two.

[Amir Kamil]

Proposed fix in 646c665.

[Dan Bonachea]

New wording looks good to me - thanks Amir!