Re: [Boost-mpi] Thread API

Subject: Re: [Boost-mpi] Thread API
From: Matthias Troyer (troyer_at_[hidden])
Date: 2012-11-29 06:28:23

On Nov 28, 2012, at 9:22 PM, Hal Finkel <hfinkel_at_[hidden]> wrote:

> ----- Original Message -----
>> From: "Alain O Miniussi" <alain.miniussi_at_oca.eu>
>> To: "Hal Finkel" <hfinkel_at_[hidden]>
>> Cc: "Discussion of Boost.MPI development" <boost-mpi_at_[hidden]>
>> Sent: Wednesday, November 28, 2012 12:14:44 PM
>> Subject: Re: [Boost-mpi] Thread API
>> 
>> 
>> So, to summarize, we have 3 issues:
>> 1) syntax: lower vs upper case and mt->threading.
>> 2) throw an exception if the requested level is not available
>> 3) macro to control availability of MPI[1|2|3] features
>> 
>> 1) ok, I like it better, too :-)
>> 
>> 2) exceptions  -> if I understand, it is proposed that we consider
>> the
>> unavailability of the requested level as an error and let the flag
>> 'throw_on_error' decide what to do ?
>> A few small concerns
>> * the MPI standard does not seems to consider this an error, so we
>> do a
> 
> The standard does not consider it an error, but it also assumes that the caller will check the provided level. This is a bad assumption, and we must have a better option ;)

My proposal would be the following:

  mpi::environment(argc,argv,level); // same semanrics as the C API
  mpi::environment(argc,argv,mpi::required(level)); // will throws if the level cannot be obtained

> 
>> semantic change (if I understand correctly 8.7 in MPI3)
>> * it is not clear that we are allowed to query the available
>> threading
>> support level (actually, 8.7 seems to indicated that we can't,
>> although
>> there is some weird text associated with the thread_level key of
>> INFO_ENV). That indicates that the user has no way of probing the
>> value
>> before initializing. So if we consider the use case of a user who
>> wants
>> to generally throw on error *and* is willing to adapt to the
>> available
>> threading level, such a change will make that impossible.
> 
> Okay, good point, and calling MPI_Init multiple times may not be safe. How about this: have the constructors take both a 'preferred' and 'required' level; call MPI_Init with the preferred level and throw the exception only if the provided level is below the required level. This has the advantage of being safe and easy, forcing the programming to think about the options, and is not functionally limiting. If a program really has requirements that cannot be expressed as a range in this way, they can always set the required level to the lowest one and fall back to explicit post-construction tests.

Why not just the post-construction test in this case:

  mpi::environment env(argc,argv,desired_level);
  if ( mpi::environment::thread_level() < required_level)
    throw .....

I don't think that passing two levels to the constructor is clearer. Do you regularly request a higher level than you require?

>> 
>> Any thought ?
>> 
>> 3) Ok, actually the BOOST_MPI_HAS_NOARG_INITIALIZATION would fall in
>> that category (the feature is mandatory since MPI2 I think).
>> 
>> One last question: in my patch, I am still using MPI_Init instead of
>> the
>> supposedly equivalent MPI_Init(..single..) (keept for backward
>> compatibility) I propose to only use MPI_Init_thread in the
>> implementation.
> 
> This is fine with me, so long as we're not keeping compatibility with MPI 1 implementations. Are we?

We might be - that's why I would propose to guard this with macros and use MPI_Init_thread only if we have at least MPI-2.

Matthias