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 [email protected] 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)