persona_scope argument values and defaults

Issue #73 resolved
Dan Bonachea created an issue

Currently three functions in the Progress API take a persona_scope& argument:

bool upcxx::progress_required(persona_scope &ps = top_persona_scope());
void upcxx::discharge(persona_scope &ps = top_persona_scope());
void upcxx::flush(persona_scope &ps = top_persona_scope()); 

All three functions take a persona_scope ps argument that selects a portion of the active stack of personas on the calling thread, and performs either a query or flush-like operation on that selected set of personas. In all three cases, the semantics for how ps selects a set of personas are as follows:

For the set of personas included in this thread’s active stack section bounded inclusively between ps and the current top

The default in all three cases is ps = top_persona_scope(). This means that by default only the topmost entry in the active persona stack is selected when calling these functions.

A few observations:

  1. This default differs from the (only) persona-selection behavior for the closely-related upcxx::progress() function, which unconditionally acts on all active personas.
  2. There is no localized way for a thread to traverse its current stack of active personas and get references to the various persona_scopes.
    • A persona_scope cannot be retrieved via query once a new one has been pushed.
    • I believe currently the only way to access the default persona scope is to call top_persona_scope() after init(); liberate_master_persona() and before any new scopes are pushed.
    • This means in general a context-free callee cannot get a reference to the default persona scope created at thread initiation that would select the entire active stack.
  3. As a consequence of .2, there is no localized way to change the default behavior of these calls to include all currently-active personas, which is a reasonable behavior to request (especially for the flushing operations).

I'm not sure the right way to address all this, but a few possible partial solutions:

  1. Add a call persona_scope &default_persona_scope() that can be called at any time to retrieve a reference to the scope at the "bottom" of the active persona stack (the one created by UPC++ implicitly at thread creation).
  2. Consider changing the default ps for these functions to be the default persona scope (ie they default to selecting the entire active set of personas), even if we don't explicitly expose an accessor for the "bottom" of the stack. This way context-free callees at least have a way to spell "full flush".

Comments (5)

  1. Former user Account Deleted

    Not giving access to the "bottom"/default persona is an oversight. Will add.

    The ability for the user to crawl the persona stack seems of minor use. To me, it seems similar to asking for the set of currently held locks.

    I think the default behavior of progress = full stack, and everything else is stack.top() makes sense.

  2. Dan Bonachea reporter

    To clarify, there is already a means to access the default persona: upcxx::default_persona ();
    What's missing is the means to access the default/bottommost persona scope that encloses it, since this API requires a persona_scope.

    I guess a third solution would be provide an accessor that converts persona to persona_scope, although I don't think we currently require that to be a 1:1 mapping (ie one thread could push the same persona multiple times in different scopes). Such an accessor might also encourage scopes to leak across threads, which we probably want to prohibit, as I'm assuming persona_scopes are not thread-safe objects.

    By the way, I just noticed discharge and flush are missing preconditions - they probably should have the same precondition as progress_required

  3. Log in to comment