J3/06-322r2 Date: November 8, 2006 To: J3 From: Aleksandar Donev Subject: Issues 86, 87, 90 and 73. SYNC TEAM, IMAGE_TEAM, NULL_IMAGE_TEAM Reference: J3/06-007r1, J3/06-252r2 Dependencies: UTI 89 Issues 86 (page 198), 87 (page 437), 90 (page 436) and 73 (page 436) raise concerns that can all be addressed by making IMAGE_TEAM be an extensible derived type with default initialization to an empty image set. 1. Discussion of issue 86 (page 198) The text for SYNC TEAM already requires that the image executing the statement be a member of the team, see [197:18-19]. This automatically prohibits an empty set of images. Undefined image teams are also prohibited by [197:19-20]. If IMAGE_TEAM is default initialized then there can never be an object of type IMAGE_TEAM that is undefined. The value is either an empty image set or explicitly assigned by FORM_TEAM. Edits are provided for this. 1. Discussion of issue 87 (page 437) The constant NULL_IMAGE_TEAM was introduced in response to issue 40 by J3/06-252r2, which said: "Yes, it would be a good idea to add INQUIRE(TEAM=). For symmetry with OPEN, it should return a scalar of type IMAGE_TEAM. We will need a null value for the case where the unit or file is not connected. Since the user will need to know the list of images involved, we also need to add an intrinsic that is given a scalar of type IMAGE_TEAM and returns the list of image indices." UTI 087 proposes that the derived type IMAGE_TEAM be default initialized to be an emtpy set of images. This would void the need to have a named constant for this purpose. We agree. One can test for an empty team using (SIZE(TEAM_IMAGES(team))==0). The edits reflect this. 2. Discussion of Issue 90 (page 436). The type IMAGE_TEAM is an extensible type. An edit makes this clear. Subgroup discussed whether it should have pointer or allocatable components, and concluded that all that matters is that it is made clear that a value should used for its intended purpose only on the image on which it was created. This is in case the processor uses pointer components. 3. Discussion of Issue 73 (page 436). We do not want to allow use of values of type IMAGE_TEAM across images (see UTI 89). Not even as an argument to TEAM_IMAGES, and certainly not as arguments to the SYNC statements. The data describing the team may contain image-specific information that cannot be interpreted by other images. This allows maximal implementation flexibility and we do not see it as restricting the programmer in any significant way. Edits to J3/06-007r1 [252:8] Change 'NULL_IMAGE_TEAM (13.8.3.13)' to 'that identifies an empty image set'. [430:1-2] Change the sentence "The value of TEAM_IMAGES..." to: "For a value of TEAM that identifies an empty image set, the result is an array of size zero." [436:9++] At the end of 13.8.3.7 IMAGE_TEAM add NOTE 13.25a When values of type IMAGE_TEAM are constructed by calling the collective subroutine FORM_TEAM on the images of a team, the processor may choose to store information in each to speed later processing of team synchronizations and collective subroutine calls. Since this information is likely to vary between images, it is inappropriate to copy values of type IMAGE_TEAM between images. For this reason, co-arrays of type IMAGE_TEAM are not permitted and if a value is copied from one image to another, the value becomes undefined except on the image on which it was created. END NOTE [437:21-23] Delete subclause 13.8.3.13 [436:9+] Replace the second sentence "It shall have..." with: "The type IMAGE_TEAM shall be extensible, it shall have only private components and it shall have default initialization to a value that identifies an empty image set."