Newsgroups: comp.parallel.mpi
From: gdburns@osc.edu (Greg Burns)
Subject: LAM 6.0 portability
Organization: The Ohio Supercomputer Center
Date: 28 Mar 1996 13:36:27 -0500
Message-ID: <4jem7b$5qr@tbag.osc.edu>

The MPI library in LAM 6.0 has a portability layer much like the
ADI (Abstract Device Interface) in MPICH.  In LAM it is called
the RPI (Request Progression Interface) because the MPI request
is the essential data structure and progression is the essential
challenge.

To port LAM easily, one requires a UNIX IP network, upon which
LAM's daemon process will run.  The daemon's low-level message-passing
provides some convenience in setting up the custom MPI network, establishing
a world communicator, spawning and aborting processes.  Many
aspects of these tasks are actually portable with LAM.

There are usually two RPI implementations in a port of LAM: the
daemon-based version that is 100% portable and the client-to-client
version that gets rewritten for each hi-perf network.  The RPI
consists of the following eight entry points:

_rpi_init()
	called from MPI_Init()

_rpi_addprocs()
	allows process spawning

_rpi_build()
	persistent portion of building an MPI request

_rpi_start()
	per communication portion of building an MPI request

_rpi_destroy()
	undoes _rpi_build()

_rpi_finalize()
	called from MPI_Finalize()

_rpi_iprobe()
	an oddball due to MPI_Iprobe which is non-blocking but is
	not associated with an MPI request

_rpi_advance()
	The Meat.  You have a list of requests.  Make progress.
	You may be allowed to block indefinitely.

	This is admittedly rather high level function.  But anything
	lower will probably convince the porting engineer that the
	portable interface cramps his/her ability to eek out the highest
	performance from the custom system.  The portable LAM MPI
	library does entirely shield the RPI implementor from the
	mundane travails of data types, user buffers, and communicators
	as well as the nasty problems associated with cancelling and
	(blocking/non-blocking/persistent) buffered sends.

-=-
Greg Burns				gdburns@osc.edu
Ohio Supercomputer Center		http://www.osc.edu/lam.html

