[mpi-21] Ballot 4 - Re: [mpi-forum] MPI_Startall / MPI_Waitall / MPI_Testall clarification?

Rolf Rabenseifner rabenseifner at [hidden]
Wed Feb 6 11:37:20 CST 2008



Dries,

Sounds fine. Nobody raised problems with this clarification up to now.
 
Please can you write a full proposal of exactly what to change/add/...

I would put it to MPI 2.1 Ballot 4.

Best regards
Rolf

On Mon, 4 Feb 2008 16:24:03 +0100
 Dries Kimpe <Dries.Kimpe_at_[hidden]> wrote:
>>From the standard: (same for MPI_Startall, MPI_Testall)
>
>The error-free execution of MPI_WAITALL(count, array_of_requests,
>array_of_statuses) has the same effect as the execution of
>MPI_WAIT(&array_of_request[i], &array_of_statuses[i]), for i=0 ,...,
>count-1, in some arbitrary order.
>
>What about count==0? 
>
>1) Is it allowed?  
>
>2) If it is allowed, should a valid pointer be provided as the
>array_of_requests argument?
>
>Looking at mpich-1.0.6p1, I see the following:
>
>
>Function     Allows count==0    Allows bufptr=0 when count==0
>MPI_Testall     Y                       Y
>MPI_Testsome    Y                       Y
>MPI_Testany     Y                       Y
>MPI_Waitsome    Y                       Y
>MPI_Waitall     Y                       Y
>MPI_Waitany     Y                       Y
>MPI_Startall    Y                       N
>
>For MPI_Startall:
>
>Fatal error in MPI_Startall: Invalid argument, error stack:
>MPI_Startall(147): MPI_Startall(count=0, req_array=(nil)) failed
>MPI_Startall(80).: Null pointer in parameter array_of_requests[0]0:Return code = 0, signaled with Interrupt
>
>Considering the other ...all functions allow count==0 and ignore the array
>in this case, the behaviour of MPI_Startall  is probably just an oversight
>in mpich.
>
>For some reason, OpenMPI has exactly the same behavior;
>MPI_Startall doesn't allow req_array==0 even if count==0
>(MPI_ERR_REQUEST is raised/returned)
>
>There is also an issue: progress.  For example, in OpenMPI, calling
>MPI_Testall with count==0 doesn't do anything at all. More specific, it
>doesn't call the progress engine. 
>
>Mpich however, does call the progress engine, even if count==0.
>(On the other hand, MPI_Waitall does NOT try to make progress if count==0)
>
>I propose to clarify where needed, and explicitly allow count==0;
>Also, if count==0, then 0 should be accepted as pointer for the request
>array, and no guarantee of progress should be made.
>
>If count==0, the returned error code should be MPI_SUCCESS (unless of
>course, an asynchronous error is detected).
>
>It would suffice to add "When count is zero, this call has no effect."
>(For MPI_Startall, MPI_Testall, MPI_Waitall this can be right after the
>text quoted on top of this message; For MPI_Waitany, MPI_Testany,
>MPI_Waitsome, MPI_Testsome, the addition should be at the end of the
>paragraph.)
>
>
>  Greetings,
>  Dries
>
>_______________________________________________
>mpi-forum mailing list
>mpi-forum_at_[hidden]
>http://lists.cs.uiuc.edu/mailman/listinfo/mpi-forum

Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden]
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 Mpi-21 mailing list