(j3.2006) (SC22WG5.5335) Vote on N2027

[John Reid]

WG5,

Here is my vote.

John.
-------------- next part --------------

Please answer the following question "Is N2027 ready for forwarding to 
SC22 as the DTS?" in one of these ways. 

2) Yes, but I recommend the following changes. 

[5:11+] Add
"<3.2a>
<established coarray>
coarray that is accessible within a CHANGE TEAM construct from outside 
the construct (5.1)"
Reason: The term "established" is used quite a bit. I think we need a 
definition.

[5:32+] Add
"<3.4.1>
<known failed image>
image known by the executing image to have failed (5.8)"

[10:27] Change 
"a coarray that does not appear in a <coarray-association>"
to
"a coarray that is not an associating entity".
Reason. The present wording suggests that a coarray established outside
the construct is not accessible if it appears in a <coarray-association>.

[13:5] After "image M" add "since execution last began in this team".
Reason. In an earlier execution as a team, an image might have failed
temporarily because of the failure of another image. 

[13:20] After "SYNC TEAM statement" add "or the STAT argument in an
invocation of a collective procedure". 
Reason: This case seems to have been overlooked.

[14:7+] Add paragraph
"If the executing image detects that another image has failed by 
executing an image control statement whose STAT= specifier is assigned 
the value STAT_FAILED_IMAGE or invoking a collective or atomic 
subroutine whose STAT argument is set to STAT_FAILED_IMAGE, the other
image is known by the executing image to have failed. If the failure 
has occurred as described in the previous paragraph, the image ceases 
to be known as having failed after execution of the relevant END TEAM  
statement."
Reason. We need a clear definition of the term "known failed image". It
is currently buried in the result value paragraph of 7.4.16 FAILED_IMAGES.

[16:17-20+] Swap the text of Note 6.3 with the text of the paragraph in 
lines 17-20.
Reason. The text in the paragraph seems unsuitable to be definitive 
text. It is the sequence of changes of the value of the event variable 
that matters, as given in the note. 

[17:19] Change "atomic memory operations" to "atomic actions".
Reason. This is the terminology that we are using, see earlier in this 
paragraph.

[17:32+] In NOTE 7.1, line 1, after "atomic subroutine" add 
"without a STAT argument". 
Reason. I think the intention is for the call to be lightweight and fast 
if there is no STAT argument but to make a check that all is well with 
the image if STAT is present.

[18:14] After "zero" and "if no image in the current team is detected 
as failed and STAT_FAILED_IMAGE otherwise".
Reason: We need to regard a collective as successful even if it detects
failed images, see [18:2-3]. 

[18:21-22] Delete sentence "If an ... STAT_FAILED_IMAGE."
Reason: We need to regard a collective as successful even if it detects
failed images, see [18:2-3]. 

[19:25] Change "bitwise AND" to "atomic".
[19:38] Change "compare" to "atomic".
[20:4] Change "compare and swap" to "atomic".
[20:15&19] Change "add" to "atomic".
[20:30&34] Change "bitwise AND" to "atomic".
[21:5&9] Change "bitwise OR" to "atomic".
[21:20&24] Change "bitwise exclusive OR" to "atomic".
[21:36] Change "bitwise OR" to "atomic".
[22:9] Change "bitwise exclusive OR" to "atomic".
Reason. In all these cases, it is the atomic nature of the operation 
that is important. What is done has already been stated. 

[22:11, 22:16, 22:24, 22:31, 22:33, 22:40, 22:42, 23:11, 23:13, 23:20, 
23:22, 23:33, 23:36, 23:40, 23:42 twice, 24:3, 24:5, 24:21, 24:23, 
24:30, 24:32] Add "nonfailed" before "images".
[22:26, 23:6, 23:28, 24:15] Change "current team of images" to 
"nonfailed images of the current team".
Reason. Consistency with 7.3 para 1. 

[22:20, 22:38, 23:18, 24:1, 24:28, 25:5, 28:28] Delete "default".
Reason: We do not need to require these STAT arguments to be of type
default integer. 

[24:37] Delete ", ERRMSG".
[25:6-8] Delete "ERRMSG ... the argument."
Reason. None of the other atomic subroutines have an ERRMSG argument. 

[25:31-35] Delete sentence "If the executing image ... failed."
Reason: Let's instead have a clear definition in 5.8.

[27:20] Before "have initiated" add "are known to".
[27:25] Before "have initiated" add "be known to".
[27:26] Change "has initiated" add "is known to have initiated".
[27:27] Before "have initiated" add "are known to".
Reason: This should be like FAILED_IMAGES and only list the images it
already knows have stopped. 

[29:21-22] Change
"number of failed images in the team specified, otherwise the result is 
the number of nonfailed images in the team specified" 
to
"number of images in the team specified that are known to have failed, 
otherwise the result is the number of images in the team specified that
are not known to have failed".
Reason. NUM_IMAGES should use the list of failed images that the image
has. 

[31:24] Change "which" to "that". 
Reason. The STAT value STAT_FAILED_IMAGE just indicates that an image 
has failed and FAILED_IMAGES only lists the images the executing image
already knows have failed. 

[31:26 to 32:27] Replace by
"{In 1.3 Terms and definitions, insert the new terms of Clause 3 of this
Technical Specification.}"
Reason. It is safer to define the terms once in the TS. 

[35:13] Replace  "as many times as has image M" by 
"{\ul in the current team} as many times as has image M 
{\ul since execution last began in this team}".
Reason. On leaving a CHANGE TEAM construct, we need to ignore the 
SYNC ALLs executed within it because their numbers may differ. 

[35:16] Change "3" to "4".
[35:21+] Add para:
"Execution of a SYNC IMAGES statement performs a synchronization of the 
image with each of the other {\ul nonfailed} images in the <image-set>. 
Executions of SYNC IMAGES statements on images M and T correspond if
the number of times image M has executed a SYNC IMAGES statement 
{\ul in the current team} with T in its image set {\ul since execution 
last began in this team} is the same as the number of times image T has 
executed a SYNC IMAGES statement {\ul in the current team} with M in 
its image set {\ul since execution last began in this team}. The 
segments that executed before the SYNC IMAGES statement on either 
image precede the segments that execute after the corresponding
SYNC IMAGES statement on the other image."
Reason. We need to allow for failed images in SYNC IMAGES in just the
same way as in SYNC ALL. Note that both are mentioned in 5.8 at 
[13:20].

[37:1-] In the entry for EVENT QUERY, Delete ", ERRMSG".
Reason. None of the other atomic subroutines have an ERRMSG argument. 

[38:3] After "description" add "and a paragraph".
[38:4+] Add "if an error condition occurs, the ATOM argument becomes
undefined".
Reason. We do the equivalent for ATOMIC_REF.

[39:10] Change "failed ... nonfailed images" to "images in the team 
specified that are known to have failed or the number that are not 
known to have failed". 
[39:15-16] Change "failed ... specified" to "images in the team 
specified that are known to have failed; otherwise, the result is the
number that are not known to have failed". 
Reason. NUM_IMAGES should use the list of failed images that the image
has. 

[40:15+} Add
"{In 13.8.2.24 STAT_STOPPED_IMAGE, insert new paragraph after 
paragraph 1}
If the executing image detects that another image has stopped by 
executing a statement whose STAT= specifier is assigned 
the value STAT_STOPPED_IMAGE or invoked a collective or atomic 
subroutine whose STAT argument is set to STAT_STOPPED_IMAGE, the other
image is known by the executing image to have stopped. "
Reason. We need a clear definition of the term "known stopped image".