Adjust ~dist_object() wording
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.
Comments (12)
-
-
reporter 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
-
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.
-
reporter 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.
-
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.
-
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.
-
reporter 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.
-
You're right, I was conflating the two.
-
reporter - changed component to Distributed Objects
-
assigned issue to
-
reporter - changed milestone to 2017.09.30 release
-
Proposed fix in 646c665.
-
reporter - changed status to resolved
New wording looks good to me - thanks Amir!
- Log in to comment
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: