Closed spophale closed 1 year ago
Updated the original post with a snapshot of the use-case from our Google Drive drafts folder: https://drive.google.com/open?id=1eN7aBxyzPD0a_GJFq1KH2ZHpoONj76op
As I was working on this use case, I ran into a question on PMIX_MODEL_PHASE_NAME
and PMIX_MODEL_PHASE_TYPE
. Those events/declarations strike me as conceptually similar to PMIX_MODEL_RESOURCES
or PMIX_OPENMP_PARALLEL_ENTERED
, that is they are dynamic declarations that happen repeatedly at runtime. The way they are declared in the standard and the code has them listed as attributes passed to PMIx_Init
along with attributes like PMIX_MODEL_LIBRARY_NAME
, that is static attributes that can be declared a single time at the start. Is there a way to dynamic update the phase that the model is in?
I guess you are assuming these attributes get passed to PMIx_Init
simply because they are defined in the same section of the Standard as the other ones? If so, that is an incorrect assumption - we simply gathered all the model-related attributes in one place. There is no intended implication as to when/how each of them would be used based on their location in the doc.
In this case, both PMIX_MODEL_PHASE_NAME
and PMIX_MODEL_PHASE_TYPE
would definitely be dynamic and updated by the user as they wish. I think there is no place in the doc where we explain that as there is no specific API for making that declaration - it is just another use of PMIx_Notify_event
. Maybe what we need is an "event" chapter to explain all the various things one does with events?
In this case, both PMIX_MODEL_PHASE_NAME and PMIX_MODEL_PHASE_TYPE would definitely be dynamic and updated by the user as they wish.
Ok. Cool. Thanks for that clarification. Presumably that update would look something like:
pmix_proc_t myproc;
PMIx_Init(&myproc, NULL, 0)
PMIX_INFO_CREATE(info, 2);
PMIX_INFO_LOAD(&info[0], PMIX_MODEL_PHASE_NAME, "shuffle", PMIX_STRING);
PMIX_INFO_LOAD(&info[1], PMIX_MODEL_PHASE_TYPE, "data-exchange", PMIX_STRING);
PMIx_Notify_event(PMIX_SUCCESS, myproc, PMIX_RANGE_GLOBAL, INFO, 2,
cbfunc, NULL);
PMIX_INFO_FREE(info, 2);
Does that seem right/close?
Close - you wouldn't want to pass a status of PMIX_SUCCESS
, but rather a dedicated status that indicates a phase change. Something like a generalized version of PMIX_OPENMP_PARALLEL_ENTERED
to indicate you are entering the phase, and PMIX_OPENMP_PARALLEL_EXITED
for when you exit it. I don't see definitions for something non-OpenMP specific, sadly, so you might need to create them.
I don't see definitions for something non-OpenMP specific, sadly, so you might need to create them.
Thanks! I think that was what was tripping me up. Is there a range of pmix_status_t values reserved for implementation/application-specific values? Or is the entire range reserved for standardized values? I guess what I'm trying to get at is: is the only way to create a new pmix_status_t via the standardization process, or is it possible to create implementation-specific ones as a proof-of-concept before standardizing?
You can always define your own - you have two choices:
use a value beyond PMIX_EXTERNAL_ERR_BASE
- e.g., PMIX_EXTERNAL_ERR_BASE-1
. Remember, the error codes are negative, so you need to be "more negative than" PMIX_EXTERNAL_ERR_BASE
use a positive error status. The library is strictly using negative values, per the standard, but it doesn't care what value (positive or negative) you use in your app.
HTH
This use case was accepted into the v5.0 standard as part of PR #328. Is there any more work to do on it at the moment, or should we close it?
The v5.0.x PR https://github.com/pmix/pmix-standard/pull/328 included this use case. The issue will remain open for further discussion on this topic.
Brief Description
Hybrid applications (i.e., applications that utilize more than one programming model, such as an MPI application that also uses OpenMP or PGAS) are growing in popularity, especially as chips with increasingly large numbers of cores and processors proliferate. Unfortunately, the various models currently operate under the assumption that they alone control execution. This leads to conflicts in hybrid applications. Deadlock of parallel applications can occur when one model prevents the other from making progress due to lack of coordination between the multiple programming models [1]. Sub-optimal performance can also occur due to uncoordinated division of hardware resources between the programming models [2] [3]. This use-case offers potential solutions to the problem by providing a pathway for programming models to coordinate their actions.
Use Case Details
Identifying Active Programming Models
The current state-of-the-practice for programming models to detect one another is via set environment variables. For example, OpenMP looks for environment variables to indicate that MPI is active. Unfortunately, this technique is not completely reliable as environment variables change over time and with new software versions. Also, the fact that an environment variable is present doesn't guarantee that a particular programming is in active use since Resource Managers routinely set environment variables "just in case" the application needs them. PMIx provides a reliable mechanism by which each library can determine that another library is in operation.
\When initializing PMIx, programming models can register themselves, including their name, version, and threading model. This information is then cached locally and can then be read asynchronously by other programming models using PMIx's Event Notification system (see next section for more details).
This initialization mechanism also allows libraries to share knowledge of each other's resources and intended resource utilization. For example, if OpenMP knows which hardware threads that MPI is using it could potentially avoid processor and cache contention.
Interface
PMIx_Init
Attributes
Code Example
Coordinating at Runtime
The PMIx Event Notification system provides a mechanism by which the resource manager can communicate system events to applications, thus providing applications with an opportunity to generate an appropriate response. Hybrid applications can leverage these events for cross-library coordination.
Programming models can access the information provided by other programming models during their initialization using the event notification system. In this case, programming models should register a callback for the
PMIX_MODEL_DECLARED
event.Programming models can also use the PMIx event notification system to communicate dynamic information, such as entering a new application phase (
PMIX_MODEL_PHASE_NAME
) or a change in resources used (PMIX_MODEL_RESOURCES
). This dynamic information can be broadcast to other programming models using thePMIx_Notify_event
function. Other programming models can register callback functions to run when these events occur (i.e., callback functions) usingPMIx_Register_event_handler
.Interfaces
Status Codes
Code Example
Registering a callback to run when another programming model initializes:
Notifying an event:
Coordination at Runtime with Multiple Event Handlers
Coordinating with a threading library such as OpenMP creates the need for separate event handlers for threads of the same process. For example in an MPI+OpenMP hybrid application, the MPI thread and the main OpenMP thread may both want to be notified anytime an OpenMP worker thread enters a parallel region. This requiring support for multiple threads to potentially register different event handlers against the same status code.
Multiple event handlers registered against the same event are processed in a chain-like manner based on the order in which they were registered, as modified by directive. Registrations against specific event codes are processed first, followed by registrations against multiple event codes and then any default registrations. At each point in the chain, an event handler is called by the PMIx progress thread and given a function to call when that handler has completed its operation. The handler callback notifies PMIx that the handler is done, returning a status code to indicate the result of its work. The results are appended to the array of prior results, with the returned values combined into an array within a single pmix_info_t as follows:
The current PMIx standard does not actually specify a default ordering for event handlers as they are being registered. However, it does include an inherent ordering for invocation. Specifically, PMIx stipulates that handlers be called in the following categorical order:
Interfaces
Attributes
Status Codes
Code Example
From the OpenMP master thread:
From the MPI thread:
References