[Mpi3-ft] Piggybacking API

[Greg Bronevetsky]

>That helps a little except for the fact that the spec is the spec and
>the APIs will be documented
>and available for all to see.  I also believe that most general purpose
>MPI libraries will be aiming
>to support the full specification.  So subsetting will not be a complete
>hall pass to ignore the PB
>calls nor would I recommend ignoring them.
>
>Note, I was just wondering if there was a different way to support this
>feature than doubling the
>amount of send apis.

There are two types of complexity: API complexity and implementation 
complexity. Increasing the number of MPI calls relates to both but 
does not correlate exactly. The inclusion of collective communication 
increases both types of complexity. However, the inclusion of the 
PMPI functions doubles the number of function calls in the API but 
has minimal impact on both types of complexity. The piggybacking API 
is really aimed to increase implementation complexity a little by 
addressing a real need out there that is not served by current MPI 
implementations. Regardless of how we expose this new implementation 
complexity to users, we do need this new capability. Given that, the 
major goal becomes: how to expose this to users in a way that 
minimizes API complexity.

To this end, I think that we need to break the API up into two 
components: user API and tool API. The user API makes up the bulk of 
the spec and represents the portions of the spec that are meant to be 
used by regular application developers. The tool API in MPI 2 is 
essentially the PMPI interface. However, I am hoping that it will 
grow to include the piggybacking API as well as the idea that every 
non-local blocking MPI function call should have a corresponding 
non-blocking variant. Seen in this light, the new additions have a 
minimal impact on the complexity of the API: they simply represent 
new points where tools can intercept and adjust the activities of 
user API functions. For example, PMPI+piggybacking can be used by 
tools to attach control information to application communication and 
PMPI+nonblocking can be used to allow any tool to perform its own 
synchronization without worrying that it will cause deadlock with the 
application's communication. In this sense it doesn't matter if we 
duplicate every call in the spec because this duplication is only 
visible to tools and can be implemented fairly easily because each of 
these APIs have only a single key feature that needs to be replicated 
across many MPI calls. In this sense the duplication associated with 
the tool API is closely related to aspect-oriented programming.

In short, I believe that function call duplication associated with 
additions to the tool API is a natural part of how any tool API would 
operate. Because each new duplicated function represents a new tool 
attachment point for the same capability, rather than a new 
capability, this duplication represents minimal increases in API and 
implementation complexities. The primary complexity is in 
implementing the new required functionality and is thus, a tool 
complexity and not an API complexity.

Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1 at llnl.gov