(j3.2006) (SC22WG5.4255) [ukfortran] Question on locks

[N.M. Maclaren]

On Apr 21 2010, Reinhold Bader wrote:
>Aleksandar Donev schrieb:
>[...]
>> As a programmer, I hope that a SYNC MEMORY is not required when using 
>> LOCKS. The latter is meant to be used for user-defined ordering, i.e., 
>> in cases where the compiler cannot determine that some ordering might 
>> occur. For LOCK/UNLOCK this is clearly spelled out and so compilers 
>> cannot optimize in ways that break programs that conform to the segment 
>> ordering rules.
>>   
>While I share this hope, the description of SYNC MEMORY together with 
>the spin lock example
>Note 8.41 appears to contradict this. From Note 8.41 I conclude that 
>SYNC MEMORY serves two
>purposes
>
>(1) prevent code movement across the segment boundary
>(2) reload coarrays from memory upon first reference after the new 
>segment starts
>
>and I have the feeling that (1) is addressed by the semantics of locks, 
>but (2) isn't.

No, I think that you have misunderstood.  What locks don't provide is
a barrier - i.e. a polint at which two images synchronise, and everything
before is before, and everything after is after.  They provide a one-way
ordering.

Specifically, 8.5.6 paragraph 5 specifies that SYNC MEMORY is not needed
in the case where a segment ends in an UNLOCK statement, and another
segment starts with a LOCK statement on the same variable.  In that case,
the first segment precedes the second.  However, the segment preceding
the LOCK is unordered with respect to the sequence following the UNLOCK.

NOTE 8.41 could be improved by changing the namwe LOCKED, because it ISN'T
using locks!  It's using atomics.  They do not synchronise memory.

Regards,
Nick Maclaren.