Thank you for your response.
Please allow me to clarify my intentions. My system implements a "pipe and
filter" architecture. For example, there are many independent tasks (seperate
executables) that are connected via a "pipe". These independent tasks have 1+
inputs and 1+ outputs. The task inter-dependencies are determined at runtime
through a config script.
In MPI terms, each task might be created through a seperate call to
MPI_Comm_spawn. Each task has one (and only one) MPI process associated with
it. Since these are independent tasks, they establish communications with
each other through MPI_Comm_connect/accept (with the exception of the
connection to the master, as that was established through the spawn). Any one
task may have many incoming intercomms and many outgoing intercomms. Simply
stated, I am trying to build a very dynamic network of tasks with MPI as the
comm protocol.
I looked into MPI_waitany and if more than one operation is completed, the
returned one is chosen arbitraily. I'd like to maintain some ordering.
Additionally, I have no desire to complete more than one receive at a time (as
is offered by some other the other wait commands).
I'm not sure that merging intercomms is the right solution based on the
dynamic nature of this system (new tasks can join/exit at any time). So I
think there should probably be seperate intercomms.
Based on the description above, does MPI sound like a viable solution to my
system? I just need a generic message passing protocol -- a basic way to
transfer bytes from one independent task to another task.
|
