J3/98-191r1 To: J3 From: Matthijs van Waveren Subject: VOLATILE requirement (specs/syntax/edits) Date: July 13, 1998 The first page of this document has been passed in the J3 meeting of February 1998. 1. Specification The VOLATILE attribute and statement specify that the object associated with it may be accessed or changed by a cause from outside the scope of the standard. 2. Syntax We propose to introduce an attribute form and a statement form. The following is an illustra- tion of the syntax: • Attribute form: REAL, VOLATILE :: A • Statement form: VOLATILE [::] A 3. Description An object can have the VOLATILE attribute in a specific scoping unit but need not have it in other scoping units. In this, it has the same scoping and inheritance rules as the ASYNCHRO- NOUS attribute. It is intended that a VOLATILE variable may be referenced or defined by non-Fortran means during execution of a Fortran program. The Fortran processor must attempt to use the most recent definition when a value is required. Likewise it should attempt to make the most recent Fortran definition available. It is the programmers responsibility to manage the interactions with the non-Fortran processes. Any variable that affects the sequence of storage units associ- ated with a object with the VOLATILE attribute, also needs to be declared with the VOLA- TILE attribute. On the use and constraints of the attribute and statement the following. A procedure and a function shall have an explicit interface, if the procedure has a dummy argument that has the VOLATILE attribute. An array with vector-valued subscripts can not be a dummy argument with a VOLATILE attribute. A local variable declared in the specification-part or internal- subprogram-part of a pure subprogram shall not have the VOLATILE attribute. If the POINTER and VOLATILE attributes are both specified, then the volatility shall apply to the target of the pointer and not to the pointer association. If the PARAMETER attribute is speci- fied, the VOLATILE attribute shall not be specified. 4. List of Edits All references in the following are to 98-007r2. • [10:46+] Add to syntax rule R214: or volatile-stmt • [18:35] Add to section 2.5.4: When a data object with the VOLATILE attribute is given a value via a means as listed in sec- tion 5.1.2.x, it is considered to be defined. • [53:39+] Add to syntax rule R503: or VOLATILE • [54:43+] Add an extra constraint after R506: Constraint: If the PARAMETER, INTRINSIC, or EXTERNAL attributes are specified, then the VOLATILE attribute shall not be specified. • [66:10+] Add a new section: 5.1.2.x VOLATILE attribute An object shall have the VOLATILE attribute, if: (1) there is a reference to or definition of the object not specified by the execution sequence of 2.3; or (2) the object is an actual argument to a non-Fortran procedure which violates the argument association rules of 14.6.1.1. An object may have the VOLATILE attribute in a specific scoping unit but need not have it in other scoping units. If an object has the VOLATILE attribute, then all its sub-objects also have the VOLATILE attribute. NOTE The Fortran processor should attempt to use the most recent definition when a value is required. Likewise it should attempt to make the most recent Fortran definition available. It is the programmer’s responsibility to manage the interactions with the non-Fortran processes. END NOTE If the POINTER and VOLATILE attributes are both specified, then the volatility shall apply to the target of the pointer and to the pointer association. • [71:4+] Add a new section: 5.3.x VOLATILE statement R5xx volatile-stmt is VOLATILE [::] object-name-list Constraint: The PARAMETER attribute shall not be specified for an object-name. The VOLATILE statement declares the VOLATILE attribute (5.1.2.x) for a list of objects. • [211:33-36] Change in section 11.3.2 the text between Note 11.8 and 11.9 to the following: The local name of an entity made accessible by use association may appear in no other speci- fication statement that would cause any attribute (5.1.2) of the entity to be respecified in the scoping unit that contains the USE statement, except that it may appear in a PUBLIC or PRI- VATE statement in the scoping unit of a module and it may be given the ASYNCHRONOUS or VOLATILE attribute. • [217:27] Change (2) (f) in section 12.3.1.1 from: A dummy argument that has the ASYNCHRONOUS attribute, or to: A dummy argument that has the ASYNCHRONOUS or VOLATILE attribute, or • [318:37+] Add to section 14.7.5: (23) An object with a VOLATILE attribute that is changed by a means as listed in 5.1.2.x becomes defined. • [361:5+] Add the following section: J3 Note: The copyright issues of adding the example in the text need to be resolved before the section C.2.x is added to the final version of the standard. End J3 Note. C.2.x The VOLATILE attribute The following example illustrates the usage of the VOLATILE attribute in the case of Remote Memory Access (RMA). RMA allows one process to specify all communication parameters, both for the sending side and for the receiving side. Since the other process may not know which data in its own memory might be accessed, we need the VOLATILE attribute in order to specify the "volatility" of the data. The example shows how to implement the generic indirect assignment A = B(map), where A, B, and map have the same distribution, and map is a permutation. We assume a block distribution with equal size blocks. The example originates from the MPI-2 Standard Document, Chapter 6 (July 18, 1997, Message Passing Interface Forum), with the addition of the VOLATILE attribute. SUBROUTINE MAPVALS(A, B, map, m, comm, p) ! ! USE MPI ! ! *** Subroutine arguments ! INTEGER m ! extent of index, target and ! source arrays INTEGER map(m) ! index array INTEGER comm ! communicator, specifies group ! of processes INTEGER p ! REAL A(m) ! target array REAL, VOLATILE :: B(m) ! source array ! ! *** Local variables ! INTEGER sizeofreal ! size of real in bytes INTEGER win ! handle to window in memory ! accessible by other processes INTEGER ierr ! error number INTEGER i ! INTEGER j ! rank of target INTEGER k ! displacement from window start ! to the beginning of the target ! buffer ! ! *** Executable code ! ! *** ! CALL MPI_TYPE_EXTENT(MPI_REAL, sizeofreal, ierr) ! ! *** Creation of a memory window of size m*sizeofreal by each ! *** process in comm that is accessible by remote processes. ! CALL MPI_WIN_CREATE(B, m*sizeofreal, sizeofreal, & MPI_INFO_NULL, comm, win, ierr) ! ! *** Synchronisation of Remote Memory Access calls on win within ! *** the group comm. ! CALL MPI_WIN_FENCE(0, win, ierr) ! ! *** ! DO i = 1, m j = map(i)/p ! calculation of rank of target k = MOD(map(i), p) ! calculation of displacement ! ! *** Data transfer from the target memory [A(i)] to the caller ! *** memory [win, B(map(i))]. ! CALL MPI_GET(A(i), 1, MPI_REAL, j, k, 1, MPI_REAL, & win, ierr) ENDDO ! ! *** Synchronisation of Remote Memory Access calls on ! *** win within the group comm. ! CALL MPI_WIN_FENCE(0, win, ierr) ! ! *** Freeing of memory windows in each process. ! CALL MPI_WIN_FREE(win, ierr) RETURN END