mpid_rhcv.tex

刚才是说明 现在是安装程序在 LINUX环境下进行编程的MPICH安装文件

\startmanpage
\mantitle{MPID{\tt \char`\_}Rhcv}{tex}{10/7/2002}
\manname{MPID{\tt \char`\_}Rhcv}
--- Invoke a predefined handler on another process 
\subhead{Synopsis}
\startvb\begin{verbatim}
int MPID_Rhcv( int rank, MPID_Comm *comm, MPID_Handler_id id, 
               const struct iovec vector[], int count, int *local_flag )

\end{verbatim}
\endvb

\subhead{Input Parameters}
\startarg{rank }{Rank of process to invoke handler on
}
\startarg{comm }{Communicator that rank is relative to
}
\startarg{id   }{Id of handler
}
\startarg{vector }{vector of {\tt struct iovec} elements containing information to
be delivered to the remote handler. 
}
\startarg{count }{Number of elements in {\tt vector
}}
\par
\subhead{Output Parameter}
\startarg{local{\tt \char`\_}flag }{The location specified by this pointer is set to one
when the operation has completed.
}
\par
\subhead{Notes}
The first element of {\tt vector} points to a predefined handler datatype that
corresponds to the handler {\tt id}; the remaining elements are data that
the handler operation needs.  The handler {\tt id} can restrict the type of
memory that {\tt vector} may point at (e.g., it may require memory allocated
with {\tt MPID{\tt \char`\_}Mem{\tt \char`\_}alloc}).
\par
The C struct type {\tt iovec} is defined in {\tt $<$sys/uio.h$>$} and is the
same structure used by the Unix {\tt readv} and {\tt writev} routines.  It has the
members
\startarg{iov{\tt \char`\_}base }{Address of block
}
\startarg{iov{\tt \char`\_}len  }{Length of block in bytes.
}
\par
{\tt MPID{\tt \char`\_}Rhcv} is a nonblocking operation.  No buffer described by the {\tt vector
}argument may be modified until the {\tt local{\tt \char`\_}flag} is set.
\par
When used to invoke the predefined handlers, the first element (that is,
{\tt vector[0]}) specifies the handler structure.  For example, to issue a
request-to-send operation, the code might look something like the following:
\begin{verbatim}
  MPID_Hid_Request_to_send_t *ptr = <code to allocate this type>
  struct iovec vector[1];
  ...
  ptr->tag = tag;
  ptr->context_id = context_id;
  ...
  vector[0].iov_base = ptr;
  vector[0].iov_len  = sizeof(*ptr);
  ...
  err = MPID_Rhcv( rank, comm, MPID_Hid_Request_to_send, 
                   vector, 1, &local_flag );
\end{verbatim}

\par
There is no requirement the that requested handler be invoked during
the call to the routine.  In fact, this routine can be implemented,
particularly in a TCP method, by simply sending a message to the
designated process.  In fact, since this routine may locally complete
(in the MPI sense), in the case where messages must be temporarily
buffered at the sender (because of flow control limits or a full
socket buffer), the message may not even have been sent by the time
it returns.
\par
When this routine returns, all parameters may be reused.  For
example, the {\tt vector} argument can be allocated off of the stack; if
{\tt MPID{\tt \char`\_}Rhcv} hasn't sent the message or invoked the handler by the
time it returns, {\tt MPID{\tt \char`\_}Rhcv} will make an internal copy of the
contents of {\tt vector} (that is, the elements of the vector, not what
they point at).
\par
\subhead{Module}
MPID{\tt \char`\_}CORE
\par
\subhead{Discussion}
Earlier drafts of ADI-3 contained the routine {\tt MPID{\tt \char`\_}Rhc} as a special
case of {\tt MPID{\tt \char`\_}Rhcv}; this special case provided a slightly more
convenient interface for the case of a single block (e.g., for a {\tt count
}of {\tt 1}).  However, many operations would not use this special case.
Here are 2 examples:
\par
The Stream routines define a separate header which is used to support
the generic implementation of the MPI collective operations.  To support
this, a count of at least 2 will be needed, with {\tt vector[0]} pointing at
the packet describing the stream operation and {\tt vector[1]} pointing at the
separate header.
\par
An {\tt MPI{\tt \char`\_}Put} with a (noncontiguous) datatype will needs
a count of at least 3: {\tt vector[0]} points to the header that
describes the basic put operation (window and offset), {\tt vector[1]} points
to a description of the datatype (if not cached at the destination),
and {\tt vector[2]} points to the actual data.
\par
In terms of implementation, for a put to a strided datatype using TCP,
we'd want to send the header describing the destination, the datatype
description, and the data.  In a shared-memory case, where the destination
window is in shared-memory, this routine may run locally.  Alternately,
or where the window is not in shared-memory, the shared-memory verison
could move some of the data into a shared-memory destination location and
enqueue an handler-activation request at the destination process.
\par
\subhead{Threads and Polling}
This routine is designed to allow (for most operations) either a
threaded or a polling implementation.  For each {\tt id} (i.e., operation
type), the operation specifies whether a polling implementation is
allowed.  Since each operation is defined by an id rather than a
function pointer, the implementation of {\tt MPID{\tt \char`\_}Rhcv} can use the {\tt id
}value to decide how to implement each operation.  In the simplest
implementation, {\tt MPID{\tt \char`\_}Rhcv} could send a message to a thread running
in the destination process and that thread could execute a function
to process the request.  However, other implementations are possible.
For example, based on the {\tt id} value, messages could be sent to a
polling routine or a thread agent.  In the simple TCP case, separate
sockets could be used for actions requiring a thread and those that
can be handled by polling.  In an implementation with shared memory,
some operations can be handled directly without invoking any code at the
destination process (for example, a window lock could access the
window directly).
\par
\subhead{Questions and Discussion}
How many handler functions need be written to implement the core?
What handler types are in the core?
\par
Should there be a multisend version of this (one that can send the
same data to multiple destinations)?
\par
Should this routine know how to recover memory (e.g., the request-to-send
structure in the example above) when the operation completes?  Should it
return an indication that the message has been sent or not, allowing the
calling routine to figure out whether it needs to handle the non-blocking
nature of the operation?
\endmanpage