Hi, first of all thanks for your time and attention.
Could you be a little more specific on which parameter should be set
or maybe in which section of the document I would find that information?
I've looked for it already and couldn't find it.
Best regards,
Pedro Petrovitch.
> From: brbarret_at_[hidden]
> To: lam_at_[hidden]
> Date: Wed, 8 Apr 2009 13:51:14 -0600
> Subject: Re: LAM: lam mpi message length without blocking
>
> 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!
>
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
_________________________________________________________________
Descubra seu lado desconhecido com o novo Windows Live!
http://www.windowslive.com.br
|
