This proposal contains modifications to the original proposal that I
submitted last September, hopefully merging in some of the ideas in the
current proposal and resurfacing some of the ideas from the original
proposal that seem to have gotten lost.
It wasn't clear to me that it was desirable or even possible to provide
a buffering mechanism which used handlers. Since Jerrel seemed to be the
biggest proponent of this, I'll leave him to submit a separate proposal.
Realtime Buffers
----------------
This section proposes an interface for associating a list of buffers with
a realtime channel.
Buffer pool creation and destruction
------------------------------------
The following function creates a buffer pool to be used with a realtime channel:
MPIRT_Bufpool_create( int nbufs, /* number of buffers */
void **bufs, /* buffer addresses */
int *counts, /* buffer counts */
MPI_Datatype *dtypes, /* buffer datatypes */
int *tags, /* buffer tags */
int strategy, /* queueing strategy */
MPI_Errhandler errhandler,/* error handler */
MPIRT_Bufpool *bufpool ); /* buffer pool handle */
The order in which buffers are added determines the order in which system will
traverse them. The tags are user supplied values that can be used to
uniquely identify a given buffer.
The following function destroys a buffer pool:
MPIRT_Bufpool_free( MPIRT_Bufpool *bufpool );
Buffer list managment
---------------------
Buffers in the pool are either available or used. Buffers become used as the
system consumes them. Used buffers can be made available to the system again
by the following function:
MPIRT_Buffer_avail( int tag,
MPIRT_Bufpool bufpool,
MPIRT_Request request ); /* active channel request */
The tag value MPIRT_BUFFERS_ALL can be used to make all buffers in the pool
available to the system.
The following functions can be used to test or wait for a specific buffer's
state to change:
MPIRT_Bufpool_test( int tag,
MPIRT_Bufpool bufpool,
MPIRT_Request request,
int *flag, /* active channel request */
MPI_Status *status );
MPIR_Bufpool_wait( int tag,
MPIRT_Bufpool bufpool,
MPIRT_Request request, /* active channel request */
MPI_Status *status );
For the above functions, the tag is the unique tag given when the
buffer was created in the buffer pool. In addition, the constants
MPIRT_BUFFERS_NEXT and MPIRT_BUFFERS_NEWEST may be given as
the buffer tag. MPIRT_BUFFERS_NEXT allows the user to wait or test
on the next buffer in the management scheme to be consumed, while
MPIRT_BUFFERS_NEWEST allows the user to wait or test on the latest
buffer that has been consumed. It is this "wildcard" functionality that
necessitates the use of buffer tags. When either of these constants is
specified, the user must have some way to determine which buffer in the
list of buffers was returned. The proposed solution is to overload the
MPI_TAG field of the status object to contain the tag of this buffer.
The current version of the document says:
"A frozen view of the buffer queue may be required for some applications.
Simple repetition of MPIRT_Buffers_get( bufpool, NEWEST, 1, index, req)
is not sufficient, since new messages may arrive between these three
operations and the the queue will be modified."
This is the whole idea behind the MPIRT_BUFFERS_NEXT flag. Using this
flag should give the next available buffer in the queueing strategy.
MPIRT_BUFFERS_NEWEST should only be used to bypass the normal strategy.
This idea seems to have been lost in successive versions of the proposal.
I may be bringing up ideas here that were shot down at the first Boston
meeting which I was unable to attend. I couldn't tell from the minutes of
that meeting what the issues were, and it isn't clear to me that the
direction the current proposal is taking is addressing them.
See y'all in San Diego.
-Ron
-------------------------------------------------------------------------------
Ron Brightwell email: bright@cs.sandia.gov
Parallel Computing Science Department www : http://www.cs.sandia.gov/~bright
Sandia National Laboratories home : (505) 292-0428
Org. 9223, MS 1110 work : (505) 844-2099
Albuquerque, NM 87185-1110 fax : (505) 845-7442