10 CHAPTER 2.MPI TERMS AND CONVENTIONS MPI_CLASS_ACTION.For C and Fortran we use the C++terminology to define the Class.In C++,the routine is a method on Class and is named 3 MPl::Class:Action_subset.If the routine is associated with a certain class,but does not make sense as an object method,it is a static member function of the class. 6 2.If the routine is not associated with a class,the name should be of the form MPI_Action_subset in C and MPI_ACTION_SUBSET in Fortran,and in C++should 8 be scoped in the MPI namespace,MPl:Action_subset. 9 3.The names of certain actions have been standardized.In particular,Create creates o a new object,Get retrieves information about an object,Set sets this information, 12 Delete deletes information,Is asks whether or not an object has a certain property. 13 C and Fortran names for some MPI functions (that were defined during the MPl-1 14 process)violate these rules in several cases.The most common exceptions are the omission 15 of the Class name from the routine and the omission of the Action where one can be 16 inferred. 17 MPI identifiers are limited to 30 characters (31 with the profiling interface).This is 18 done to avoid exceeding the limit on some compilation systems. 19 21 2.3 Procedure Specification 22 23 MPI procedures are specified using a language-independent notation.The arguments of 24 procedure calls are marked as IN,OUT or INOUT.The meanings of these are: 25 IN:the call may use the input value but does not update the argument, 27 OUT:the call may update the argument but does not use its input value, 28 9 INOUT:the call may both use and update the argument. 30 There is one special case-if an argument is a handle to an opaque object (these 31 terms are defined in Section 2.5.1),and the object is updated by the procedure call,then 32 the argument is marked INOUT or OUT.It is marked this way even though the handle itself 33 is not modified-we use the INOUT or OUT attribute to denote that what the handle 34 references is updated.Thus,in C++,IN arguments are usually either references or pointers 35 to const objects. 36 37 Rationale.The definition of MPl tries to avoid,to the largest possible extent,the use 38 of INOUT arguments,because such use is error-prone,especially for scalar arguments. 9 (End of rationale.) 40 41 MPI's use of IN,OUT and INOUT is intended to indicate to the user how an argument 42 is to be used,but does not provide a rigorous classification that can be translated directly 43 into all language bindings (e.g.,INTENT in Fortran 90 bindings or const in C bindings). 44 For instance,the "constant"MPI_BOTTOM can usually be passed to OUT buffer arguments. 45 Similarly,MPI_STATUS_IGNORE can be passed as the OUT status argument. A common occurrence for MPI functions is an argument that is used as IN by some pro- 47 cesses and OUT by other processes.Such an argument is,syntactically,an INOUT argument
10 CHAPTER 2. MPI TERMS AND CONVENTIONS MPI_CLASS_ACTION. For C and Fortran we use the C++ terminology to define the Class. In C++, the routine is a method on Class and is named MPI::Class::Action_subset. If the routine is associated with a certain class, but does not make sense as an object method, it is a static member function of the class. 2. If the routine is not associated with a class, the name should be of the form MPI_Action_subset in C and MPI_ACTION_SUBSET in Fortran, and in C++ should be scoped in the MPI namespace, MPI::Action_subset. 3. The names of certain actions have been standardized. In particular, Create creates a new object, Get retrieves information about an object, Set sets this information, Delete deletes information, Is asks whether or not an object has a certain property. C and Fortran names for some MPI functions (that were defined during the MPI-1 process) violate these rules in several cases. The most common exceptions are the omission of the Class name from the routine and the omission of the Action where one can be inferred. MPI identifiers are limited to 30 characters (31 with the profiling interface). This is done to avoid exceeding the limit on some compilation systems. 2.3 Procedure Specification MPI procedures are specified using a language-independent notation. The arguments of procedure calls are marked as IN, OUT or INOUT. The meanings of these are: • IN: the call may use the input value but does not update the argument, • OUT: the call may update the argument but does not use its input value, • INOUT: the call may both use and update the argument. There is one special case — if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call, then the argument is marked INOUT or OUT. It is marked this way even though the handle itself is not modified — we use the INOUT or OUT attribute to denote that what the handle references is updated. Thus, in C++, IN arguments are usually either references or pointers to const objects. Rationale. The definition of MPI tries to avoid, to the largest possible extent, the use of INOUT arguments, because such use is error-prone, especially for scalar arguments. (End of rationale.) MPI’s use of IN, OUT and INOUT is intended to indicate to the user how an argument is to be used, but does not provide a rigorous classification that can be translated directly into all language bindings (e.g., INTENT in Fortran 90 bindings or const in C bindings). For instance, the “constant” MPI_BOTTOM can usually be passed to OUT buffer arguments. Similarly, MPI_STATUS_IGNORE can be passed as the OUT status argument. A common occurrence for MPI functions is an argument that is used as IN by some processes and OUT by other processes. Such an argument is, syntactically, an INOUT argument 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
2.4.SEMANTIC TERMS 11 and is marked as such,although,semantically,it is not used in one call both for input and for output on a single process. Another frequent situation arises when an argument value is needed only by a subset 3 of the processes.When an argument is not significant at a process then an arbitrary value can be passed as an argument. 5 Unless specified otherwise,an argument of type OUT or type INOUT cannot be aliased 6 with any other argument passed to an MPI procedure.An example of argument aliasing in C appears below.If we define a C procedure like this, void copyIntBuffer(int *pin,int *pout,int len 10 int i; 11 for (i=0;i<len;++i)*pout++=*pin++; 12 13 then a call to it in the following code fragment has aliased arguments. 14 公 int a[10]; 16 copyIntBuffer(a,a+3,7); 17 Although the C language allows this,such usage of MPI procedures is forbidden unless 18 otherwise specified.Note that Fortran prohibits aliasing of arguments. 19 All MPI functions are first specified in the language-independent notation.Immediately below this,the ISO C version of the function is shown followed by a version of the same 电 function in Fortran and then the C++binding.Fortran in this document refers to Fortran 22 90;see Section 2.6. 23 24 25 2.4 Semantic Terms 26 When discussing MPI procedures the following semantic terms are used. 品 导 nonblocking A procedure is nonblocking if the procedure may return before the opera- 品 tion completes,and before the user is allowed to reuse resources (such as buffers) 吃 specified in the call.A nonblocking request is started by the call that initiates it, 31 e.g.,MPI_ISEND.The word complete is used with respect to operations,requests, and communications.An operation completes when the user is allowed to reuse 33 resources,and any output buffers have been updated;i.e.a call to MPI_TEST will 34 return flag true.A request is completed by a call to wait,which returns,or a test or get status call which returns flag true.This completing call has two ef- fects:the status is extracted from the request;in the case of test and wait,if the 37 request was nonpersistent,it is freed,and becomes inactive if it was persistent.A 38 communication completes when all participating operations complete. % blocking A procedure is blocking if return from the procedure indicates the user is allowed 41 to reuse resources specified in the call. 42 43 local A procedure is local if completion of the procedure depends only on the local executing process. 45 non-local A procedure is non-local if completion of the operation may require the exe- 46 cution of some MPI procedure on another process.Such an operation may require 47 communication occurring with another user process. 48
2.4. SEMANTIC TERMS 11 and is marked as such, although, semantically, it is not used in one call both for input and for output on a single process. Another frequent situation arises when an argument value is needed only by a subset of the processes. When an argument is not significant at a process then an arbitrary value can be passed as an argument. Unless specified otherwise, an argument of type OUT or type INOUT cannot be aliased with any other argument passed to an MPI procedure. An example of argument aliasing in C appears below. If we define a C procedure like this, void copyIntBuffer( int *pin, int *pout, int len ) { int i; for (i=0; i<len; ++i) *pout++ = *pin++; } then a call to it in the following code fragment has aliased arguments. int a[10]; copyIntBuffer( a, a+3, 7); Although the C language allows this, such usage of MPI procedures is forbidden unless otherwise specified. Note that Fortran prohibits aliasing of arguments. All MPI functions are first specified in the language-independent notation. Immediately below this, the ISO C version of the function is shown followed by a version of the same function in Fortran and then the C++ binding. Fortran in this document refers to Fortran 90; see Section 2.6. 2.4 Semantic Terms When discussing MPI procedures the following semantic terms are used. nonblocking A procedure is nonblocking if the procedure may return before the operation completes, and before the user is allowed to reuse resources (such as buffers) specified in the call. A nonblocking request is started by the call that initiates it, e.g., MPI_ISEND. The word complete is used with respect to operations, requests, and communications. An operation completes when the user is allowed to reuse resources, and any output buffers have been updated; i.e. a call to MPI_TEST will return flag = true. A request is completed by a call to wait, which returns, or a test or get status call which returns flag = true. This completing call has two effects: the status is extracted from the request; in the case of test and wait, if the request was nonpersistent, it is freed, and becomes inactive if it was persistent. A communication completes when all participating operations complete. blocking A procedure is blocking if return from the procedure indicates the user is allowed to reuse resources specified in the call. local A procedure is local if completion of the procedure depends only on the local executing process. non-local A procedure is non-local if completion of the operation may require the execution of some MPI procedure on another process. Such an operation may require communication occurring with another user process. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
12 CHAPTER 2.MPI TERMS AND CONVENTIONS collective A procedure is collective if all processes in a process group need to invoke the procedure.A collective call may or may not be synchronizing.Collective calls over 3 the same communicator must be executed in the same order by all members of the process group. 5 predefined A predefined datatype is a datatype with a predefined(constant)name(such 7 as MPI_INT,MPI_FLOAT_INT,or MPI_UB)or a datatype constructed with MPI_TYPE_CREATE_F90_INTEGER,MPI_TYPE_CREATE_F90_REAL,or 9 MPI_TYPE_CREATE_F90_COMPLEX.The former are named whereas the latter are 10 unnamed. 11 12 derived A derived datatype is any datatype that is not predefined. 13 portable A datatype is portable,if it is a predefined datatype,or it is derived from a 14 portable datatype using only the type constructors MPI_TYPE_CONTIGUOUS, 15 MPI_TYPE_VECTOR,MPI_TYPE_INDEXED,MPI_TYPE_CREATE_INDEXED_BLOCK. 16 MPI_TYPE_CREATE_SUBARRAY,MPI_TYPE_DUP,and MPI_TYPE_CREATE_DARRAY. 17 Such a datatype is portable because all displacements in the datatype are in terms 18 of extents of one predefined datatype.Therefore,if such a datatype fits a data lay- 19 out in one memory,it will fit the corresponding data layout in another memory,if 20 the same declarations were used,even if the two systems have different architec- tures.On the other hand,if a datatype was constructed using 22 MPI_TYPE_CREATE_HINDEXED,MPI_TYPE_CREATE_HVECTOR or 23 MPI_TYPE_CREATE_STRUCT,then the datatype contains explicit byte displace- 24 ments (e.g.,providing padding to meet alignment restrictions).These displacements 25 are unlikely to be chosen correctly if they fit data layout on one memory,but are used for data layouts on another process,running on a processor with a different 27 architecture. 28 equivalent Two datatypes are equivalent if they appear to have been created with the same 30 sequence of calls (and arguments)and thus have the same typemap.Two equivalent 31 datatypes do not necessarily have the same cached attributes or the same names. 32 33 2.5 Data Types 34 35 2.5.1 Opaque Objects 36 37 MPI manages system memory that is used for buffering messages and for storing internal 38 representations of various MPl objects such as groups,communicators,datatypes,etc.This 39 memory is not directly accessible to the user,and objects stored there are opaque:their 40 size and shape is not visible to the user.Opaque objects are accessed via handles,which 41 exist in user space.MPI procedures that operate on opaque objects are passed handle 42 arguments to access these objects.In addition to their use by MPl calls for object access, 43 handles can participate in assignments and comparisons. 44 In Fortran,all handles have type INTEGER.In C and C++,a different handle type is 45 defined for each category of objects.In addition,handles themselves are distinct objects 46 in C++.The C and C++types must support the use of the assignment and equality 47 operators
12 CHAPTER 2. MPI TERMS AND CONVENTIONS collective A procedure is collective if all processes in a process group need to invoke the procedure. A collective call may or may not be synchronizing. Collective calls over the same communicator must be executed in the same order by all members of the process group. predefined A predefined datatype is a datatype with a predefined (constant) name (such as MPI_INT, MPI_FLOAT_INT, or MPI_UB) or a datatype constructed with MPI_TYPE_CREATE_F90_INTEGER, MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_CREATE_F90_COMPLEX. The former are named whereas the latter are unnamed. derived A derived datatype is any datatype that is not predefined. portable A datatype is portable, if it is a predefined datatype, or it is derived from a portable datatype using only the type constructors MPI_TYPE_CONTIGUOUS, MPI_TYPE_VECTOR, MPI_TYPE_INDEXED, MPI_TYPE_CREATE_INDEXED_BLOCK, MPI_TYPE_CREATE_SUBARRAY, MPI_TYPE_DUP, and MPI_TYPE_CREATE_DARRAY. Such a datatype is portable because all displacements in the datatype are in terms of extents of one predefined datatype. Therefore, if such a datatype fits a data layout in one memory, it will fit the corresponding data layout in another memory, if the same declarations were used, even if the two systems have different architectures. On the other hand, if a datatype was constructed using MPI_TYPE_CREATE_HINDEXED, MPI_TYPE_CREATE_HVECTOR or MPI_TYPE_CREATE_STRUCT, then the datatype contains explicit byte displacements (e.g., providing padding to meet alignment restrictions). These displacements are unlikely to be chosen correctly if they fit data layout on one memory, but are used for data layouts on another process, running on a processor with a different architecture. equivalent Two datatypes are equivalent if they appear to have been created with the same sequence of calls (and arguments) and thus have the same typemap. Two equivalent datatypes do not necessarily have the same cached attributes or the same names. 2.5 Data Types 2.5.1 Opaque Objects MPI manages system memory that is used for buffering messages and for storing internal representations of various MPI objects such as groups, communicators, datatypes, etc. This memory is not directly accessible to the user, and objects stored there are opaque: their size and shape is not visible to the user. Opaque objects are accessed via handles, which exist in user space. MPI procedures that operate on opaque objects are passed handle arguments to access these objects. In addition to their use by MPI calls for object access, handles can participate in assignments and comparisons. In Fortran, all handles have type INTEGER. In C and C++, a different handle type is defined for each category of objects. In addition, handles themselves are distinct objects in C++. The C and C++ types must support the use of the assignment and equality operators. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
2.5.DATA TYPES 13 Advice to implementors.In Fortran,the handle can be an index into a table of opaque objects in a system table;in C it can be such an index or a pointer to the object.C++handles can simply "wrap up"a table index or pointer. 3 4 (End of advice to implementors.) 5 Opaque objects are allocated and deallocated by calls that are specific to each object 6 type.These are listed in the sections where the objects are described.The calls accept a handle argument of matching type.In an allocate call this is an OUT argument that returns a valid reference to the object.In a call to deallocate this is an INOUT argument which returns with an "invalid handle"value.MPI provides an "invalid handle"constant for each % object type.Comparisons to this constant are used to test for validity of the handle. 之 A call to a deallocate routine invalidates the handle and marks the object for deal- location.The object is not accessible to the user after the call.However,MPI need not 13 deallocate the object immediately.Any operation pending(at the time of the deallocate) 14 that involves this object will complete normally;the object will be deallocated afterwards. 15 An opaque object and its handle are significant only at the process where the object was created and cannot be transferred to another process. MPI provides certain predefined opaque objects and predefined,static handles to these 18 objects.The user must not free such objects.In C++,this is enforced by declaring the 1g handles to these predefined objects to be static const. 吃 总 Rationale.This design hides the internal representation used for MPI data struc- tures,thus allowing similar calls in C,C++,and Fortran.It also avoids conflicts with 23 the typing rules in these languages,and easily allows future extensions of functional- 24 ity.The mechanism for opaque objects used here loosely follows the POSIX Fortran 25 binding standard. 26 27 The explicit separation of handles in user space and objects in system space allows 导 space-reclaiming and deallocation calls to be made at appropriate points in the user 多 program.If the opaque objects were in user space,one would have to be very careful 吃 not to go out of scope before any pending operation requiring that object completed. 31 The specified design allows an object to be marked for deallocation,the user program 32 can then go out of scope,and the object itself still persists until any pending operations 33 are complete. 34 The requirement that handles support assignment/comparison is made since such 的 operations are common.This restricts the domain of possible implementations.The 36 alternative would have been to allow handles to have been an arbitrary,opaque type. 37 This would force the introduction of routines to do assignment and comparison,adding 38 complexity,and was therefore ruled out.(End of rationale. 吃 % Advice to users.A user may accidently create a dangling reference by assigning to a 41 handle the value of another handle,and then deallocating the object associated with these handles.Conversely,if a handle variable is deallocated before the associated 43 object is freed,then the object becomes inaccessible (this may occur,for example,if the handle is a local variable within a subroutine,and the subroutine is exited before the associated object is deallocated).It is the user's responsibility to avoid adding or deleting references to opaque objects,except as a result of MPI calls that allocate or 47 deallocate such objects.(End of advice to users.) 48
2.5. DATA TYPES 13 Advice to implementors. In Fortran, the handle can be an index into a table of opaque objects in a system table; in C it can be such an index or a pointer to the object. C++ handles can simply “wrap up” a table index or pointer. (End of advice to implementors.) Opaque objects are allocated and deallocated by calls that are specific to each object type. These are listed in the sections where the objects are described. The calls accept a handle argument of matching type. In an allocate call this is an OUT argument that returns a valid reference to the object. In a call to deallocate this is an INOUT argument which returns with an “invalid handle” value. MPI provides an “invalid handle” constant for each object type. Comparisons to this constant are used to test for validity of the handle. A call to a deallocate routine invalidates the handle and marks the object for deallocation. The object is not accessible to the user after the call. However, MPI need not deallocate the object immediately. Any operation pending (at the time of the deallocate) that involves this object will complete normally; the object will be deallocated afterwards. An opaque object and its handle are significant only at the process where the object was created and cannot be transferred to another process. MPI provides certain predefined opaque objects and predefined, static handles to these objects. The user must not free such objects. In C++, this is enforced by declaring the handles to these predefined objects to be static const. Rationale. This design hides the internal representation used for MPI data structures, thus allowing similar calls in C, C++, and Fortran. It also avoids conflicts with the typing rules in these languages, and easily allows future extensions of functionality. The mechanism for opaque objects used here loosely follows the POSIX Fortran binding standard. The explicit separation of handles in user space and objects in system space allows space-reclaiming and deallocation calls to be made at appropriate points in the user program. If the opaque objects were in user space, one would have to be very careful not to go out of scope before any pending operation requiring that object completed. The specified design allows an object to be marked for deallocation, the user program can then go out of scope, and the object itself still persists until any pending operations are complete. The requirement that handles support assignment/comparison is made since such operations are common. This restricts the domain of possible implementations. The alternative would have been to allow handles to have been an arbitrary, opaque type. This would force the introduction of routines to do assignment and comparison, adding complexity, and was therefore ruled out. (End of rationale.) Advice to users. A user may accidently create a dangling reference by assigning to a handle the value of another handle, and then deallocating the object associated with these handles. Conversely, if a handle variable is deallocated before the associated object is freed, then the object becomes inaccessible (this may occur, for example, if the handle is a local variable within a subroutine, and the subroutine is exited before the associated object is deallocated). It is the user’s responsibility to avoid adding or deleting references to opaque objects, except as a result of MPI calls that allocate or deallocate such objects. (End of advice to users.) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
14 CHAPTER 2.MPI TERMS AND CONVENTIONS 1 Advice to implementors.The intended semantics of opaque objects is that opaque objects are separate from one another;each call to allocate such an object copies 3 all the information required for the object.Implementations may avoid excessive copying by substituting referencing for copying.For example,a derived datatype 5 may contain references to its components,rather then copies of its components;a 6 call to MPI_COMM_GROUP may return a reference to the group associated with the communicator,rather than a copy of this group.In such cases,the implementation must maintain reference counts,and allocate and deallocate objects in such a way that 9 the visible effect is as if the objects were copied.(End of advice to implementors.) 10 11 2.5.2 Array Arguments 12 13 An MPI call may need an argument that is an array of opaque objects,or an array of 14 handles.The array-of-handles is a regular array with entries that are handles to objects 15 of the same type in consecutive locations in the array.Whenever such an array is used, 16 an additional len argument is required to indicate the number of valid entries (unless this 17 number can be derived otherwise).The valid entries are at the beginning of the array; 18 len indicates how many of them there are,and need not be the size of the entire array. 19 The same approach is followed for other array arguments.In some cases NULL handles are 20 considered valid entries.When a NULL argument is desired for an array of statuses,one 21 uses MPI_STATUSES_IGNORE. 22 23 2.5.3 State 24 MPI procedures use at various places arguments with state types.The values of such a data 25 type are all identified by names,and no operation is defined on them.For example,the 26 MPI_TYPE_CREATE_SUBARRAY routine has a state argument order with values 27 MPI_ORDER_C and MPI_ORDER_FORTRAN. 28 9 2.5.4 Named Constants 31 MPI procedures sometimes assign a special meaning to a special value of a basic type argu- 32 ment;e.g.,tag is an integer-valued argument of point-to-point communication operations, 33 with a special wild-card value,MPI_ANY_TAG.Such arguments will have a range of regular 34 values,which is a proper subrange of the range of values of the corresponding basic type; 35 special values (such as MPl_ANY_TAG)will be outside the regular range.The range of regu- 36 lar values,such as tag,can be queried using environmental inquiry functions (Chapter 7 of 37 the MPl-1 document).The range of other values,such as source,depends on values given 38 by other MPl routines (in the case of source it is the communicator size). 39 MPI also provides predefined named constant handles,such as MPI_COMM_WORLD. 40 All named constants,with the exceptions noted below for Fortran,can be used in 41 initialization expressions or assignments,but not necessarily in array declarations or as 42 labels in C/C++switch or Fortran select/case statements.This implies named constants 43 to be link-time but not necessarily compile-time constants.The named constants listed 44 below are required to be compile-time constants in both C/C++and Fortran.These 45 constants do not change values during execution.Opaque objects accessed by constant handles are defined and do not change value between MPI initialization (MPI_INIT)and MPI completion (MPI_FINALIZE).The handles themselves are constants and can be also used in initialization expressions or assignments
14 CHAPTER 2. MPI TERMS AND CONVENTIONS Advice to implementors. The intended semantics of opaque objects is that opaque objects are separate from one another; each call to allocate such an object copies all the information required for the object. Implementations may avoid excessive copying by substituting referencing for copying. For example, a derived datatype may contain references to its components, rather then copies of its components; a call to MPI_COMM_GROUP may return a reference to the group associated with the communicator, rather than a copy of this group. In such cases, the implementation must maintain reference counts, and allocate and deallocate objects in such a way that the visible effect is as if the objects were copied. (End of advice to implementors.) 2.5.2 Array Arguments An MPI call may need an argument that is an array of opaque objects, or an array of handles. The array-of-handles is a regular array with entries that are handles to objects of the same type in consecutive locations in the array. Whenever such an array is used, an additional len argument is required to indicate the number of valid entries (unless this number can be derived otherwise). The valid entries are at the beginning of the array; len indicates how many of them there are, and need not be the size of the entire array. The same approach is followed for other array arguments. In some cases NULL handles are considered valid entries. When a NULL argument is desired for an array of statuses, one uses MPI_STATUSES_IGNORE. 2.5.3 State MPI procedures use at various places arguments with state types. The values of such a data type are all identified by names, and no operation is defined on them. For example, the MPI_TYPE_CREATE_SUBARRAY routine has a state argument order with values MPI_ORDER_C and MPI_ORDER_FORTRAN. 2.5.4 Named Constants MPI procedures sometimes assign a special meaning to a special value of a basic type argument; e.g., tag is an integer-valued argument of point-to-point communication operations, with a special wild-card value, MPI_ANY_TAG. Such arguments will have a range of regular values, which is a proper subrange of the range of values of the corresponding basic type; special values (such as MPI_ANY_TAG) will be outside the regular range. The range of regular values, such as tag, can be queried using environmental inquiry functions (Chapter 7 of the MPI-1 document). The range of other values, such as source, depends on values given by other MPI routines (in the case of source it is the communicator size). MPI also provides predefined named constant handles, such as MPI_COMM_WORLD. All named constants, with the exceptions noted below for Fortran, can be used in initialization expressions or assignments, but not necessarily in array declarations or as labels in C/C++ switch or Fortran select/case statements. This implies named constants to be link-time but not necessarily compile-time constants. The named constants listed below are required to be compile-time constants in both C/C++ and Fortran. These constants do not change values during execution. Opaque objects accessed by constant handles are defined and do not change value between MPI initialization (MPI_INIT) and MPI completion (MPI_FINALIZE). The handles themselves are constants and can be also used in initialization expressions or assignments. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48