Sorprendentemente, MPI_Ibarrier
es una rutina muy útil. Por ejemplo, puede entregar una ronda de mensajes no estructurados a los rangos que no saben cuántos mensajes recibir al enviar con MPI_Issend
(sí, un uso poco frecuente del envío sincrónico), luego ingresar un ciclo de alternancia MPI_Testall
(para ver si los envíos se completaron) y MPI_Iprobe
(para procesar mensajes entrantes). Cuando los envíos se completan, usted publica MPI_Ibarrier
y prueba alternativamente la barrera y prueba los mensajes entrantes. Torsten Hoefler tiene un documento sobre esto en el que demuestra la optimización de la comunicación, consulte el Algoritmo 2: http://unixer.de/publications/img/hoefler-dsde-protocols.pdf
Tenga en cuenta que una barrera no garantiza que los mensajes punto a punto u otros colectivos sin bloqueo se publiquen antes de que la barrera se haya completado. Si desea que se completen, debe asegurarse de que se hayan completado antes de publicar la barrera. Como dice Bill, (bloqueo) MPI_Barrier
es incorrecto / innecesario en la mayoría de los casos. Una excepción es la comunicación a través de canales laterales, como el sistema de archivos.
Aunque no existe una forma de rendimiento similar para simular MPI_Ibarrier
con MPI-2, MPICH2 proporciona MPIX_Ibarrier
en la rama 1.5 (actual). Las redes de proveedores generalmente admiten estas operaciones, por lo que las implementaciones de proveedores (que generalmente se derivan de MPICH2) solo necesitan una interfaz. Tan pronto como sus parches se muevan a 1.5, MPI_Ibarrier
y otros colectivos sin bloqueo deberían ser compatibles. La rama de desarrollo Open MPI tiene una implementación MPI_Ibarrier
basada en libNBC.