[J3] Question not just for HPC
malcolm at nag-j.co.jp
Wed Oct 16 23:44:35 EDT 2019
>So, the whole argument here seems to hinge on the fact that x%q is not a “named variable”. Since if it were, it would have to be a coarray. Also, the LOCK statement in the example is only locking a local lock. Which is very peculiar, but apparently allowed.
Yes. I don’t think that local-locking is particularly peculiar; the lock is, after all, accessible to other images because the pointer is associated with a coarray.
I understand, and agree, that we want to make sure that any lock-variable is going to be accessible to other images, since that’s the whole point of the feature. The existing constraints do achieve that, so philosophically they are fine as is I think.
If on the other hand, we didn’t want to allow this, either we would have to make some rule for lock_type and pointer components, or in this case we could make it “useless” by requiring the lock-variable to be a coarray or coindexed.
Oh, and I think similar analysis applies to events, but I’ve not checked up on that. Of course EVENT WAIT is always local, so that case would not be at all peculiar.
My gut feeling is that it’s not actually harmful (apart from being a source of compiler bugs!), and although I would certainly agree that its usefulness is limited (but not quite zero), it looks like it would be more trouble than it’s worth to try to prohibit it, and prohibiting it could also make something else look peculiar (depending on how we do it). But I’m still open to opinions to the contrary.
..............Malcolm Cohen, NAG Oxford/Tokyo.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3