On Fri, 11 Jun 2004, Michael Lees wrote:
> I was thinking about the proposed two thread solution which I had
> originally posted. This is of course only efficient if the MPI_recv call
> is also implemented with signaling and condition variables? It's no use
> removing the polling from the threads if the blocking recv polls too?
Essentially correct -- the issue is blocking vs. polling; the blocking is
not dependant upon signaling and condition variables.
> How does lam implement a blocking receive is it done with signaling or
> with polling?
It depends. :-\
If we're blocking only on TCP sockets, we simply sit in a select() or a
read(), which typically blocks nicely. If we're blocking only on shared
memory, it depends on which rpi module you are using -- usysv will poll
while sysv will block. For Myrinet, we poll because the GM equivalent of
a blocking read is very expensive.
All of this is done in the name of reducing latency -- polling is best
when you want the lowest latency, and it assumes that you have a full CPU
to burn while waiting.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
