Boost logo

Boost-MPI :

Subject: Re: [Boost-mpi] Thread API
From: Alain O Miniussi (alain.miniussi_at_[hidden])
Date: 2012-12-04 04:40:07


To sum up what I got from the comments regarding the threading API, do
we agree that we only want to basically to mimic the underlying C-Init,
that is:
- provide an environment ctor with only one preferred threading support
level.
- provide a query method to probe the provided support level (user code
will need to check if it is ok with it).
- scan the documentation and make sure that any usage of such a ctor is
followed by a checking of the provided level ?
- if no level is provided, assume "threading::single" (which we do not
need to test, since that the minimal level)

If that ok, I'll try to provide a patch accordingly.

Thanks

On Thu, 2012-11-29 at 12:04 -0600, Hal Finkel wrote:
> ----- Original Message -----
> > From: "Matthias Troyer" <troyer_at_[hidden]>
> > To: "alain miniussi" <alain.miniussi_at_oca.eu>
> > Cc: "Discussion of Boost.MPI development" <boost-mpi_at_[hidden]>
> > Sent: Thursday, November 29, 2012 7:21:09 AM
> > Subject: Re: [Boost-mpi] Thread API
> >
> >
> > On Nov 29, 2012, at 1:11 PM, Alain O Miniussi <alain.miniussi_at_oca.eu>
> > wrote:
> > >
> > > That being said, I do not have a strong opinion between:
> > > a) provide a 2 argument ctor
> > > b) provide one argument ctor, and test provided level afterward.
> > >
> > > I just have a preference for b, because I find it simpler (both in
> > > terms
> > > of API and explanation, one thing I did not mention is that we
> > > could as
> > > weel abort if the requirement is not met in the ctor, since we
> > > won't be
> > > able to do any MPI related stuff after that, so going into a lot of
> > > trouble to explain the status of env seems unjustified), and that
> > > throwing in ctor has it's own set of issue (if only being
> > > controversial).
> >
> > Actually throwing in the constructor if we cannot acquire a resource
> > (here MPI with required level of thread support) is just the RAII
> > idiom. There are no problems with that and it is actually good
> > style.
> > >
> > > One thing to consider is that if the requirement is not met, we
> > > probably
> > > want to explain what's going on to the user. Which will require
> > > some
> > > code. So the test "if (provided < required) { ... }" won't add a
> > > lot of
> > > trouble anyway.
> >
> > I agree. If the requested level is not met we will need to test
> > anyway which level we got.
>
> Fair enough. Maybe the best thing to do is just to make sure that we actually do this test is all of the documentation snippets and example code.
>
> -Hal
>
> >
> > Matthias
> >
> >
> > _______________________________________________
> > Boost-mpi mailing list
> > Boost-mpi_at_[hidden]
> > http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
> >
>

-- 
Alain Miniussi
Responsable Tech. Centre de Calcul Haute Performance
Obs. de la Côte d'Azur |Mont Gros: +33 4 92 00 30 09
BP 4229                |Sophia :   +33 4 83 61 85 44
06304 Nice Cedex 4     |https://crimson.oca.eu

Boost-Commit list run by troyer at boostpro.com