(j3.2006) DEALLOCATE and image control

Malcolm Cohen malcolm
Sun Apr 6 02:18:47 EDT 2014


I wrote:
> Well the processor had better not do that then.  For that matter
>   DEALLOCATE(coarray1,coarray2)
> had better not deadlock (no allocatable components in sight here).

Van Snyder suggested:
>Perhaps it ought to be stated that all images shall deallocate
><allocate-object>s in the same order, and all allocatable components in
>the same order.

That seems unnecessary and potentially harmful.

The standard states
  "When a DEALLOCATE statement is executed for which an allocate-object is a 
coarray, there is an implicit synchronization of all images."

That is not "there is a separate implicit sync of all images for each 
coarray object being deallocated", that is there is ONE implicit 
synchronisation for the whole DEALLOCATE statement.  Therefore order of 
deallocation of the items simply does not come into question.

Now it *might* be that a processor implements this with two micro-syncs 
before and after each object is being deallocated, but that is not how it is 
described in the standard and it is up to the processor to implement the 
facilities so they appear to the user as they are described in the standard. 
(In my opinion it is not particularly likely that a processor would sync 
around each individual object deallocation anyway - that would, I think, 
likely lead to a loss of performance.)  But if the processor chooses to 
implement the single (standard) implicit sync with a technique that relies 
on some ordering of multiple deallocations in the DEALLOCATE statement, it 
is up to the processor to do whatever it is that it needs to do so that it 
all works - whether that needs the ordering to be the same, or not.

I do not think there is any doubt that a processor which implements 
DEALLOCATE in a way that prevents execution from continuing afterwards is 
not standard-conforming, no matter how the vendor weasels with "well, the 
standard doesn't say how long it takes to transfer control to the next 
statement" or whatever.  We do not actually need any more words here, and we 
should not want to specify any of the possible implementation details.

Cheers,
-- 
..........................Malcolm at home.




More information about the J3 mailing list