[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 
(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_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
   -- With new values for
       - required_/provided_ft_mode =   
           MPI_FT_NONE=0, or
       - required_/provided_cancel_mode =   
           MPI_CANCEL_ALLOWED=0, or  
       - required_/provided_any_source_mode = 
           MPI_ANY_SOURCE_ALLOWED=0, or 
   -- 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.
        - 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,
           - 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, 
           - 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

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