|
Avoid deadlock by intelligent arrangement of sends/receives, or by posting non-blocking receives early. If you choose to use blocking transactions, try to guarantee that deadlock will be avoided by carefully tailoring your communication strategy so that sends and receives are properly paired and in the necessary order; alternatively, post non-blocking receives as early as possible, so that the sends will stay in the system for as little time as is necessary.
Use the appropriate "operation-status" call ("wait", "test", or "probe") to control the operation of non-blocking communications calls. Correctly knowing the state of communications transactions allows the application to intelligently steer itself to better efficiency in its use of available cycles. Ultimately pending traffic must be accepted, but that action can be long in coming and much can possibly be accomplished while it is incomplete. The wait, test and probe calls allow the application to match the appropriate activity with the particular situation.
Check the value of the "status" fields for problem reports. Don't just assume that things are running smoothly -- make it a general rule that every transaction is checked for success, and that failures are promptly reported and as much related information as possible is developed and made available for debugging.
Intelligent use of wildcards can greatly simplify logic and code. Using general receives, receives capable of handling more than one kind of message traffic (in terms of either sender, or message-type, or both), can greatly simplify the structure of your application, and can potentially save on system resources (if you are in the habit of using a unique message buffer for each transaction).
Null processes and requests move tests out of user code. Use of MPI_PROC_NULL and MPI_REQUEST_NULL does not get rid of boundary tests, it simply allows the programmer to use a call that will be ignored by the system.
|
