>Two of the portal primitives include read-memory and write-memory to
>a "window" in a process' address space on a remote node.
Can the process open any piece of its address space to remote access
(stack, heap, data etc). Can a process open all its address space to remote
access (i.e., one giant linearly addressed window).
How does a remote process specify the location to read/write in the window?
(Byte offset from the start of the window?)
What are the guaranteed memory semantics - ordering, and atomicity? Is the
window guaranteed to be (cache) coherent under all implementations?
>(I'm afraid I don't fully understand Eric's use of "arbitrary" with respect
>to remote process address'.
Arbitrary in the sense that any part of the processes address space can be
shareable (stack, heap, data etc). In addition, the process can open its
entire address space by specifying something like MPI_BOTTOM. This implicitly
assumes that the address space is linearly addressable.
>I'm not sure what a shared memory buffer would look like on an
If there are no special hardware resrictions, a shared memory buffer might
implemented using malloc() (from the application heap). The application could
use this buffer in any normal way. The basic restriction is one of programming
convenience: the application must use shared buffers created by the MPI
system, instead of the convenience of using structures on the stack or static
data, or using existing heap buffers created by malloc(). However, I note
IBM's need for writing compilers, (or libraries?), in which explictly managing
buffers is not possible as they are already defined in some other way.
>(hrecv is not an implementation option for us).
Does this mean you would have a problem implementing the proposed hrecv()?
Hughes Aircraft Co.
X-Mailer: ELM [version 2.3 PL11]