[Mpi3-ft] MPI_INIT_THREAD and MPI_Failhandler_set/get_mode at MPI initialization
Rolf Rabenseifner
rabenseifner at hlrs.de
Tue Jan 17 04:31:10 CST 2012
Dear committees of
- FT,
- MPI_Init --> 8. Environmental Management,
- MPI_Init_thread --> 12. External Interfaces.
Before discussing details, I would like to get a clear answer
whether you believe that the proposal below is a good or bad idea.
As already mentioned at the Jan. 2012 meeting, I would like to propose
that the FT group may substitute the unclear collective behavior
of MPI_Failhandler_set_mode by adding the mode to the MPI initialization.
For this, I added a proposal to slide 4 in
MPI_Forum_Overview_MPI-3.0_Jan2012_action-items.ppt
(see my previous mail to the MPI-Forum list)
- If appropriate, a new ticket that enhances MPI_INIT_THREAD
-- Required and provided as “bit vector” of "bit-wise OR" of
required_/provided_threadsafety
| required_/provided_ft_mode
| required_/provided_cancel_mode
| required_/provided_any_source_mode
-- New mask-constants MPI_THREAD_MASK, MPI_FT_MASK,
MPI_CANCEL_MASK, MPI_ANY_SOURCE_MASK
-- With existing values for required_/provided_threadsafety
MPI_THREAD_SINGLE, MPI_THREAD_FUNNELED,
MPI_THREAD_SERIALIZED, and MPI_THREAD_MULTIPLE.
-- With new values for
- required_/provided_ft_mode =
MPI_FT_NONE=0, or
MPI_FT_FAILHANDLER_MODE_ALL≠0, or
MPI_FT_FAILHANDLER_MODE_SUBSET≠0, or
- required_/provided_cancel_mode =
MPI_CANCEL_ALLOWED=0, or
MPI_NO_CANCEL≠0
- required_/provided_any_source_mode =
MPI_ANY_SOURCE_ALLOWED=0, or
MPI_NO_ANY_SOURCE≠0
-- Values must be set identical for all processes in an MPI_COMM_WORLD
- It is easier to relax about this in further versions of MPI
than to relax already now and to restrict later
as now done in ticket #222 for required_/provided_threadsafety
- For each of the for "variables", a different decision
can be done.
-- At least for required_/provided_cancel_mode and
...any_source_mode, I would require that the provided
value must be identical to the required value.
Reason: Internally, the value can be ignored.
-- For required_/provided_ft_mode, I would recommend
to allow that provided_ft_mode must be
- identical to required_ft_mode or MPI_FT_NONE
- and the same in all processes.
-- MPI_INIT_THREAD & MPI_QUERY_THREAD moves
- from 12.4.3 (External Interfaces)
- to 8.7 (Startup)
- but explanations to ...threadsafety | ...ft_mode |
...cancel_mode | ...any_source_mode are kept or written
in the appropriate sections 12.4.3, new 17.5 (FT Environm.),
3.8.4 (Cancel), 3.2.4 (Blocking Receive)
-- A call to MPI_INIT is identical to MPI_INIT_THREAD with
- the rules in 12.4.3 about required_/provided_threadsafety
- required_/provided_ft_mode = MPI_FT_NONE,
- required_/provided_cancel_mode = MPI_CANCEL_ALLOWED,
- required_/provided_any_source_mode = MPI_ANY_SOURCE_ALLOWED
-- This ticket would have the following properties:
- It is clearly source-code and ABI backward compatible,
because
- the values of MPI_THREAD_SINGLE, _FUNNELED, ...
need not to be changed and MPI_THREAD_SINGLE need
not to be zero;
- the values representing the current MPI-2.2 quality
are set to zero: MPI_FT_NONE=0,
MPI_CANCEL_ALLOWED=0, and MPI_ANY_SOURCE_ALLOWED=0
- It is very unlikely that an implementation has used
more than 24 different bits in these 4 integer
constants MPI_THREAD_SINGLE, ... _MULTIPLE.
Therefore MPI_THREAD_MASK would have a maximum
of 24 bits. Enough room for the 4 bits needed
together for the other three ..._MASKs.
- FT can be switched on or off at the MPI initialization
and is switched off in unchanged applications.
Therefore no backward-compatibility-problem with a
modified behavior of the default error handlers
when FT is switched on.
- Normally there should be enough bit-space for further
decisions at MPI initialization.
- The decisions about the cancel and any_source
values would be done in different tickets
- FT quality is optional if we add the
rule that provided_ft_mode may be identical
to required_ft_mode ***or*** MPI_FT_NONE
- This rule can be changed in a further version of MPI
without backward-compatibility-problems.
I would like to get a reply from
- the FT group
- the chapter committee of MPI_Init --> 8. Environmental Manag.
George Bosilca(c), Josh Hursey, Terry Dontje
- the chapter committee of MPI_Init_thread --> 12. External Interf.
Bronis R. de Supinski(c), Pavan Balaji
Before discussing details, I would like to get a clear answer
whether you believe that this is a good or bad idea.
Best regards
Rolf
--
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
More information about the mpiwg-ft
mailing list