(j3.2006) (SC22WG5.4079) Some minor points on the Draft Final CD

Aleksandar Donev adonev
Wed Sep 9 13:29:50 EDT 2009


Hello,

Most of these have been covered already, but:

> If not, there needs to be something (even just a NOTE) clarifying
> what happens in these cases.
You are right that 6.6 does not cover declarations, but I am not sure 
what you want the Note concerning declarations to say? It has nothing 
to do with the number of images---it merely sets the lower and upper 
cobounds, which is independent of the number of images. Please suggest 
specific wording so we know what you are asking for.

> 3) I think that the current wording overspecifies error termination
> in paragraph 4 of 2.3.5 (Execution sequence).  Specifically,
> requiring one image to be able to force with others into termination
> without them executing any special statement is a heavy burden on
> implementors, and may not always be feasible.
You are talking about ALL STOP. This is certainly a necessary 
functionality. How well it is implemented, i.e., what actually happens 
when it is executed, seems (almost?) entirely processor dependent to me 
and I do not see how we are burdening or requiring anyone to do too 
much.

> If people agree with me, I suggest changing:
>
>     The synchronization step is executed by all images.
>
> to:
>
>     For normal termination, the synchronization step is executed by
> all images; for error termination, the synchronization of images is
> processor dependent.

Can someone explain to me how a program can detect the difference 
between these and how it can tell anything about what happens after ALL 
STOP is executed. All execution stops and the program cannot tell 
anything about synchronization etc.

The synchronization is there to ensure that shared data does not 
disappear until all images are done accessing it. In the case of error 
termination, it does not matter----no more accessing, no more nothing, 
execution ends. What is left to the OS (a whole lot of hanging 
processes, a clean slate, a memory leak, or sheer peace and quiet) 
seems entirely unspecified (and unspecifiable) to me.

Best,
Aleks

-- 
Aleksandar Donev, Ph.D.
Luis W. Alvarez Postdoctoral Fellow
Center for Computational Sciences and Engineering (https://ccse.lbl.gov)
Lawrence Berkeley National Laboratory (http://www.lbl.gov)
E-mail: adonev at lbl.gov
Phone: (510) 486-5782  Fax: (510) 486-6900
Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720
Web: http://cims.nyu.edu/~donev/



More information about the J3 mailing list