Gilles Gouaillardet <gilles.gouaillar...@gmail.com> writes: > Dave, > > yes, this is for two MPI tasks only. > > the MPI subroutine could/should return with an error if the communicator is > made of more than 3 tasks. > an other option would be to abort at initialization time if no collective > modules provide a barrier implementation. > or maybe the tuned module should have not used the two_procs algorithm, but > what should it do instead ? use a default one ? do not implement barrier ? > warn/error the end user ? > > note the error message might be a bit obscure. > > I write "could" because you explicitly forced something that cannot work, > and I am not convinced OpenMPI should protect end users from themselves, > even when they make an honest mistake.
I just looped over the available algorithms, not expecting any not to work. One question is how I'd know it can't work; I can't find documentation on the algorithms, just the more-or-less suggestive names that I might be able to find in the literature, or not. Is there a good place to look? In the absence of a good reason why not -- I haven't looked at the code -- but I'd expect it to abort with a message about the algorithm being limited to two processes at some stage. Of course, this isn't a common case, and people probably have more important things to do.
