To: J3 J3/13-344r1 From: Bill Long, John Reid Subject: Comments on atomics Date: 2013 October 14 References: N1983, N1989 Discussion - Responses with edits --------------------------------- {Bill I7}: At [15:15-16] In the case of an optional OLD argument to an atomic subroutine, the code generated is different depending on whether OLD is present or not. This is a side effect of economizing on subroutine names by using the same name for two operations. If the user writes an OLD argument into the call, it will almost always be the case that it will be referenced soon after the call. We need to say that an optional OLD argument that appears shall be present. Allowing the not-present actual corresponding to an optional argument is of very little value in this case and allowing it incurs both a readability and performance penalty. Edits are provided. {Steve 2}: In ATOMIC_ADD change "ATOM becomes defined with the value of ATOM+VALUE" to "ATOM becomes defined with the value of ATOM + INT(VALUE,ATOMIC_INT_KIND)". The change makes the style more like the descriptions of the other atomics. And it avoids the problem of VALUE being too large magnitude to be represented by an integer of KIND ATOMIC_INT_KND, which would be problematic to implement. Edit included below. {Nick 23}: The atomic subroutines must specify that their ATOM argument is a coarray, in the same way as ATOMIC_DEFINE and ATOMIC_REF. Edits are provided for each new Atomic subroutine. {Van 18, 19, 19a, 20, 21}: In the description of the OLD arguments to atomics, "scalar of the same type as ATOM" -> "scalar and of type integer with the same kind as ATOM". Edits are provided for each affected atomic subroutine. {Van 22}: At [16:18] Delete "to have its". Misc additional minor edits are also included. Discussion - Responses without edits ------------------------------------ {Van 17}: At [15:11-13] First two sentences are redundant. Delete the first one. Response: These sentences were directly copied from F2008/10-007r1 at [315:12-14] and should not be edited here. {Reinhold C}: Request to specify a memory model for atomic functions (beyond the current model). Possible side effects for EVENT statements. Response: Defer to {Nick 22}. {Malcolm Reason 2}: An explicit memory model for atomics [beyond what is currently in F2008] is needed for both users and vendors. Response: Defer to {Nick 22}. {Nick 22}: 7.2 p15:13-15. This specification will cause massive confusion, and it was clear from WG5 in Delft that there was no agreement on even the minimal semantics specified by Fortran. In particular, several people were assuming levels of consistency that are not always available in existing hardware, and would need extra work in the compiler to provide. At the very least, there needs to be a Note saying clearly and explicitly that currently their behavior is deliberately left entirely processor-dependent, and WG5 intends to provide a proper semantic specification in due course. Response. Users of existing implementations have been using remote atomic memory operations as part of the SHMEM library, UPC, and Fortran with coarrays for over a decade on several hardware architectures without having been confused. In the worst case, atomic operations can always be implemented using a global lock that is acquired each time an operation is done. Obviously you would not want that implementation for performance reasons, but it is an option for systems that do remote communication by email or some other very slow mechanism. But we do not want the semantics implied by that implementation for all implementations. {Dan 7}: For atomic_and,or,xor, why not type logical? Response: Typically atomic hardware supports bitwise operations for these cases. Whether that will work for LOGICAL depends on the internal representation of LOGICAL values. It might work, but effectively imposes a limitation on the implementation. {Van 23}: At [16:35] It's hard to justify "swap" in the description of a subroutine in which only one argument has INTENT(INOUT). Swap what with what? Response: The term "compare and swap" is common in the computer science lexicon. Using another description would be needlessly confusing. The second object involved in the swap is split into two parts, NEW on the way in and OLD on the way out. This allows NEW to be a constant, which is a common usage case. Note that the "and swap" part is conditional depending on the outcome of the compare. Edits to N1983 -------------- !!![15:17] {Bill I7} Add a new sentence: "An optional OLD argument of an !!!atomic subroutine shall not be an optional dummy argument." [16:7] {Bill I7} Change "ATOMIC_ADD (ATOM, VALUE [,OLD])" to "ATOMIC_ADD (ATOM, VALUE) or ATOMIC_ADD (ATOM, VALUE, OLD)". [16:11] {Nick 23} Change "scalar" to "a scalar coarray or coindexed object". [16:13] {Steve 2} In ATOMIC_ADD change "ATOM becomes defined with the value of ATOM+VALUE" to "ATOM becomes defined with the value of ATOM + INT(VALUE,ATOMIC_INT_KIND)". [16:15] {Van 18} Change "scalar of the same type as ATOM" to "scalar and of type integer with the same kind as ATOM" [16:15] {Bill I7} Delete "(optional)" [16:15-16] {Bill I7} Change "If it is present, it is" to "It is". [16:18] {Van 22} Delete "to have its". [16:21] {Bill I7} Change "ATOMIC_AND (ATOM, VALUE [,OLD])" to "ATOMIC_AND (ATOM, VALUE) or ATOMIC_AND (ATOM, VALUE, OLD)". [16:25] {Nick 23} Change "scalar" to "a scalar coarray or coindexed object". [16:25] {Van m38} Change "a" to "the". {Consistency with [16:12].} [16:29] {Van 19} Change "scalar of the same type as ATOM" to "scalar and of type integer with the same kind as ATOM" [16:29] {Bill I7} Delete "(optional)" [16:29-30] {Bill I7} Change "If it is present, it is" to "It is". [16:32-33] {Van m39} Change "Iold" to "IOLD" twice. [17:1] {Nick 23} Change "scalar" to "a scalar coarray or coindexed object". [17:5] {Nick m40} After "NEW if it" insert "is". [17:6] {Nick m41} At the end of the description of ATOM add a new sentence: "If the value of ATOM is not equal to the value of COMPARE, the value of ATOM is not changed." [17:7] {Van 19a} Change "scalar of the same type as ATOM" to "scalar and of type integer with the same kind as ATOM" [17:13] {Bill I7} Change "ATOMIC_OR (ATOM, VALUE [,OLD])" to "ATOMIC_OR (ATOM, VALUE) or ATOMIC_OR (ATOM, VALUE, OLD)". [17:17] {Nick 23} Change "scalar" to "a scalar coarray or coindexed object". [17:17] {Van m43} Change "a" to "the". {Consistency with [16:12].} [17:21] {Van 20} Change "scalar of the same type as ATOM" to "scalar and of type integer with the same kind as ATOM" [17:21] {Bill I7} Delete "(optional)" [17:21-22] {Bill I7} Change "If it is present, it is" to "It is". [17:23-24] {Van m44} Change "Iold" to "IOLD" twice. [17:26] {Bill I7} Change "ATOMIC_XOR (ATOM, VALUE [,OLD])" to "ATOMIC_XOR (ATOM, VALUE) or ATOMIC_XOR (ATOM, VALUE, OLD)". [17:30] {Nick 23} Change "scalar" to "a scalar coarray or coindexed object". [17:30] {Van m45} Change "a" to "the". {Consistency with [16:12].} [17:34] {Van 21} Change "scalar of the same type as ATOM" to "scalar and of type integer with the same kind as ATOM" [17:34] {Bill I7} Delete "(optional)" [17:34-35] {Bill I7} Change "If it is present, it is" to "It is". [17:36-37]] {Van m46} Change "Iold" to "IOLD" twice. [29:40-41] and [30:2-3] Change four times "(ATOM, VALUE [,OLD])" to "(ATOM, VALUE) or (ATOM, VALUE, OLD)"