On Sat, 24 Nov 2007, Philippe Combes wrote:
> Brian Barrett wrote :
>> On Nov 24, 2007, at 11:06 AM, Philippe Combes wrote:
>>
> Thank you for the explanation.
>
>> Note that calling MPI_CANCEL on a request does not actually mean that
>> it's cancelled. You have to call MPI_TEST_CANCELLED on the request to
>> determine if the MPI either 1) has cancelled the request or 2) will
>> complete the communication.
>
> It is not exactly how I understood the man pages.
> MPI_TEST_CANCELLED can only be called on a status, which in turn is set by a
> completion function such as MPI_WAIT or MPI_TEST.
> My problem here is that the MPI_WAIT I call right after the MPI_CANCEL never
> returns, although the standard specifies clearly that it MUST return (with
> either completion or cancellation of the request).
> I first assumed it was due to this LAM_RQFSACTIVE state, but this might be
> wrong: what should I looked for ?
If MPI_WAIT is blocking, that's a good indication that the request wasn't
cancelled. If you're worried about whether the request will be cancelled
or not (with sends, you should be at all times), you should use MPI_TEST
instead of MPI_WAIT. If your blocking MPI_WAIT is on the send side, that
means that the match information was set (transfering the request to the
active state). In order for the request to complete, the receiver must
still post the receive and the information must be sent. If the blocking
MPI_WAIT is on the receive side, then that likely means that the match
information was received already and the request will block until it
completes. In order to complete, the sender will have to enter the
progress engine (ie, enter the MPI library) and continue sending the data.
Brian
--
Brian Barrett
LAM/MPI Developer
Make today a LAM/MPI day!
|
