LAM/MPI logo

LAM/MPI General User's Mailing List Archives

  |   Home   |   Download   |   Documentation   |   FAQ   |   all just in this list

From: Brian Barrett (brbarret_at_[hidden])
Date: 2009-04-08 15:51:14


On Apr 7, 2009, at 1:08 AM, Davide Cesari wrote:

> Pedro Petrovitch ha scritto:
>> I've experienced a lock at my program while using the the pattern
>> that guarantees that it won't lock,
>> if the send isn't blocking (I use a MPI_Send and then a MPI_Recv
>> for both processes). The lock just started to happen
>
> Well, MPI_Send and MPI_Recv ARE blocking functions, so, if the
> communication pattern is such that it may create a deadlock (or as
> you say, it will not deadlock only if communication is not
> blocking), then you will probably experience locking at a certain
> message size.

Davide's absolutely correct - MPI_Send may block at any time. With
LAM, they may block at any message size (including 0 byte) depending
on queue sizes. If your code can't run with all calls to MPI_Send
replaced to MPI_Ssend (synchronous send), your code is not correct.

>> when the messages being transfered got bigger. I've made some
>> research about it and found out that there was
>> something called MP_EAGER_LIMIT in IBM's implementation that let
>> the user set the size of messages without
>> the need of using rendesvouz protocol. Is there something like that
>> in LAM's implementation?
>
> I think there is something similar also for LAM, maybe at
> compilation time, don't know for sure, but it is not wise to rely on
> it for avoiding blocking, if you want to guarantee portability and
> reliability for your application, you had better use MPI_Isend and/
> or MPI_Irecv at the cost of a slightly more complex code.

The parameter to be set depends on the underlying device, and setting
it for some devices is not a good idea. Have a look at the LAM/MPI
user's guide (http://www.lam-mpi.org/using/docs/) for more information.

Brian

-- 
   Brian Barrett
   LAM/MPI Developer
   Make today a LAM/MPI day!