To: J3 J3/13-344 From: Bill Long, John Reid Subject: Comments on atomics Date: 2013 September 30 References: N1983, N1989 Overview -------- This paper contains a portion of the responses to the comments in N1989, the results of the ballot on the TS 18508 draft N1983. The following identifiers are used to indicate the source of comments: Reinhold : Reinhold Bader Bill : Bill Long Tobias : Tobias Burnus Nick : Nick Maclaren Daniel : Daniel Chen Dan : Dan Nagel Malcolm : Malcolm Cohen John : John Reid Steve : Steve Lionel Van : Van Snyder along with {Ed} for the document editor. 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 should probably say that and optional OLD argument that appears shall be present. Response: Agreed. 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. An edit is 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)". Response: Agreed. 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}: These [atomic subroutines] must specify that their [ATOM] argument is a coarray, in the same way as ATOMIC_DEFINE and ATOMIC_REF. Response. Agreed. 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" or "scalar and of type integer with the same kind as ATOM" (whichever is really intended). Response: Make the change in the second alternative. Edits are provided for each affected atomic subroutine. {Van 22}: At [16:18] Delete "have its". Response: Delete "to have its". An edit is provided. Discussion - Responses only --------------------------- {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 at all. 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 ingrained 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: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:18] {Van 22} At [16:18] Delete "have its". [16:25] {Nick 23} Change "scalar" to "a scalar coarray or coindexed object". [16:29] {Van 19} Change "scalar of the same type as ATOM" to "scalar and of type integer with the same kind as ATOM" [17:1] {Nick 23} Change "scalar" to "a scalar coarray or coindexed object". [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:17] {Nick 23} Change "scalar" to "a scalar coarray or coindexed object". [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:30] {Nick 23} Change "scalar" to "a scalar coarray or coindexed object". [17:34] {Van 21} Change "scalar of the same type as ATOM" to "scalar and of type integer with the same kind as ATOM"