[Mpi3-tools] Changes to the MPI_T*_ document

[Martin Schulz]

Hi all,

I created a new version of the MPI_T document based on
the feedback from the MPI forum plus some additional
comments. The new draft is at:

https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/MPI3Tools/mpit/mpi-report.21.pdf

Please take a look at it and see if any more changes are
necessary. To meet the two week rule, we have until 9/8
to post the document to the MPI forum.

I don't think we need another tools TelCon until then (but
please speak up if you think we do or if there are any
other topics to cover), but I still would like feedback
on the questions that I sent around in the last email -
so far I have only heard from Bronis; additional feedback
would be helpful.


A) Naming: MPI_T or a different name? 
==============================

I have changed all names to be MPI_T_<lowercase>, but
I have not made any further name changes. Bronis's vote 
was for keeping just the "T" and that would be the easiest and
least disruptive to both the document and the existing
prototype(s). Does anybody have a good idea or a
strong opinion about this? 


B) Types: which types to support?
==========================

The new document has the following list:
MPI_INT
MPI_UNSIGNED
MPI_UNSIGNED_LONG
MPI_UNSIGNED_LONG_LONG
MPI_COUNT
MPI_CHAR
MPI_DOUBLE

With the following rationale included in the text:

The \MPI/ tool information interface relies mainly on unsigned
datatypes for integer values since most variables are expected
to represent counters or resource sizes. \const{MPI\_INT} is
provided for additional flexibility and is expected to be used
mainly for control variables. 

Providing all basic datatypes, in particular providing all signed
and unsigned variants of integer types, would lead to a larger
number of types, which tools need to interpret. This would
cause unnecessary complexity in the implementation of tools
based on the \MPI/ tool information interface.


C) Signal safety
=============

I liked Bronis's version of the text and included it in the document.
I'll also start a separate email with Brian to get his feedback.


If there are any other pending issues with this document, please
let me know. I really hope we can make the next first reading the
last reading, but for this it would be extremely helpful if more
people would look over the document!

Thanks!

Martin




On Aug 17, 2011, at 4:37 PM, Bronis R. de Supinski wrote:

> 
> Martin:
> 
> Re:
>> - Naming: People didn't like MPI_T_ and wanted something
>> more expressive. MPI_Tool_ would be the obvious choice
>> and that would be fine with me. Does anyone have a better
>> suggestion? We can't spend more than four characters on
>> it, though, or we will run into problems with the max. name
>> size (even after shortening some names). Also, I would like
>> this to be the final name change :).
> 
> I still feel that MPI_T is the best choice. No matter
> what prefix you choose, someone will not like it.
> 
> [snip]
> 
>> - We had some lengthy discussion on the thread and async
>> signal safety. Below is a suggestion for a rewrite - once I get
>> some feedback from our group, I will forward this to Brian,
>> since he had the most issues with the current wording.
>> 
>> \begin{implementors}
>> Sampling based tools rely on the ability to call the MPI
>> tool information interface, in particular routines to start, stop,
>> read, write and reset performance variables, from any program
>> context, including asynchronous contexts such as signal handlers.
>> MPI implementations should strive, if possible in their particular
> 
> OK through the above.
> 
>> environment, to enable this behavior for all or a subset of the
> 
> Which "behavior"? You do not define any behavior above. You
> define support for usage scenarios. Change to:
> 
>  environment, to enable these usage scenarios for all or a subset of the
> 
>> routines mentioned above. If implementing only a subset, the
>> read, write, and reset routines are typically the most critical
> 
>> for sampling based tools. If an MPI implementation
>> is not able to provide such a behavior or if the behavior is only
>> guaranteed under certain circumstances (e.g., for certain signals),
>> this should be clearly documented, e.g., through the description
>> return by {\mpifunc MPI\_T\_Get\_info}.
> 
> "such a"? UGH! Poor antecedent for "this". "return by"? Huh?
> 
> change to:
> 
>  for sampling based tools. An MPI implementation should clearly
>  document any restrictions on the program contexts in which
>  the MPI tool information interface can be used. Restrictions
>  might include guaranteeing usage outside of all signals or
>  outside a specific set of signals. Any restrictions could be
>  documented, for example, through the description returned by
>  {\mpifunc MPI\_T\_Get\_info}.
> 
>> \end{implementors}
> 
> Bronis
> 

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA