(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