On Dec 2, 2014, at 8:22 AM, Tom Clune <[log in to unmask]> wrote:

> Bill,
> 
> Regarding your last point:
> 
> On Dec 2, 2014, at 8:59 AM, Bill Long <[log in to unmask]> wrote:
> 
> <snip>
> 
>> A stalled image is not executing additional statements, at least until the other images get to the END TEAM statement, at which point the stalled image can come back to life.  Again, the answer depends on the scope of “communicate”.    If other images try to execute a SYNC ALL, for example, the stalled image will not participate.  On the other hand, remote reference and definition of variables on a stalled image should succeed, including atomic modifications.  Operationally, a stalled image is similar to a STOPPED image. Remote reference and definition still work, but the stalled/stopped image is not executing program statements, so will not execute ones that are supposed to be executed collectively, except for END TEAM (for stalled) or STOP/END PROGRAM (for stopped).
> 
> My (admittedly limited understanding) is that a stalled image will more-or-less jump to the END TEAM construct after unwinding the stack, deallocating various co-arrays, and so on.    This seems to complicate the above.    Seems likely that one would end up with a cascade of stalled images, often expanding to all images even in relatively simple scenarios.

It is possible that all of the active images in the team will try to access a failed image, in which case they would all end up stalled.  Accessing data on a stalled image is not supposed to cause the accessor to stall.   However, if the unwinding happens immediately, the access might be to a coarray that was deallocated, which is a problem.  So you make a good point that the “without synchronization of coarray deallocations” is probably an mistake in the text.   After all, there is a reason why deallocations are synchronized. 

> 
> Or is it the case that the unwinding does not happen until the active images reach END TEAM?   This would seem to be more difficult to manage.
> 

This does seem like the right implementation.  

Cheers,
Bill



> Cheers,
> 
> - Tom
> 
> 
> 
>> 
>> 
>> Cheers,
>> Bill
>> 
>> 
>> 
>>> 
>>> Thanks
>>> 
>>> Anton
>> 
>> Bill Long                                                                       [log in to unmask]
>> Fortran Technical Suport  &                                  voice:  651-605-9024
>> Bioinformatics Software Development                     fax:  651-605-9142
>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
> 
> Thomas Clune, Ph. D. 				<[log in to unmask]>
> Head ASTG,Code 606
> NASA GSFC		
> MS 610.8 B33-C128
> Greenbelt, MD 20771
> 301-286-4635
> 
> 
> 
> 
> 
> 
> 
> 
> 

Bill Long                                                                       [log in to unmask]
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101