Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ИНСАЙД ИНФА MPI.pdf
Скачиваний:
15
Добавлен:
15.04.2015
Размер:
3.3 Mб
Скачать

1

2

22

CHAPTER 2. MPI TERMS AND CONVENTIONS

2.7 Processes

3

4

5

An MPI program consists of autonomous processes, executing their own code, in an MIMD style. The codes executed by each process need not be identical. The processes communicate via calls to MPI communication primitives. Typically, each process executes in its own

6address space, although shared-memory implementations of MPI are possible.

7

8

9

This document speci es the behavior of a parallel program assuming that only MPI calls are used. The interaction of an MPI program with other possible means of communication, I/O, and process management is not speci ed. Unless otherwise stated in the

10speci cation of the standard, MPI places no requirements on the result of its interaction

11with external mechanisms that provide similar or equivalent functionality. This includes,

12but is not limited to, interactions with external mechanisms for process control, shared and

13remote memory access, le system access and control, interprocess communication, process

14signaling, and terminal I/O. High quality implementations should strive to make the results

15of such interactions intuitive to users, and attempt to document restrictions where deemed

16necessary.

17

18Advice to implementors. Implementations that support such additional mechanisms

19for functionality supported within MPI are expected to document how these interact

20with MPI. (End of advice to implementors.)

21

22

23

The interaction of MPI and threads is de ned in Section 12.4.

24

2.8 Error Handling

 

25

 

26MPI provides the user with reliable message transmission. A message sent is always received

27correctly, and the user does not need to check for transmission errors, time-outs, or other

28error conditions. In other words, MPI does not provide mechanisms for dealing with failures

29in the communication system. If the MPI implementation is built on an unreliable underly-

30ing mechanism, then it is the job of the implementor of the MPI subsystem to insulate the

31user from this unreliability, or to re ect unrecoverable errors as failures. Whenever possible,

32such failures will be re ected as errors in the relevant communication call. Similarly, MPI

33itself provides no mechanisms for handling processor failures.

34Of course, MPI programs may still be erroneous. A program error can occur when

35an MPI call is made with an incorrect argument (non-existing destination in a send oper-

36ation, bu er too small in a receive operation, etc.). This type of error would occur in any

37implementation. In addition, a resource error may occur when a program exceeds the

38amount of available system resources (number of pending messages, system bu ers, etc.).

39The occurrence of this type of error depends on the amount of available resources in the

40system and the resource allocation mechanism used; this may di er from system to system.

41A high-quality implementation will provide generous limits on the important resources so

42as to alleviate the portability problem this represents.

43In C and Fortran, almost all MPI calls return a code that indicates successful completion

44of the operation. Whenever possible, MPI calls return an error code if an error occurred

45during the call. By default, an error detected during the execution of the MPI library

46causes the parallel computation to abort, except for le operations. However, MPI provides

47mechanisms for users to change this default and to handle recoverable errors. The user

48may specify that no error is fatal, and handle error codes returned by MPI calls by himself