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

[Reinhold Bader]

N.M. Maclaren schrieb:
[...]

>> 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.

Thanks, I think this is what I needed to know.

> 
> 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.

This was understood. It was the role of SYNC MEMORY which was unclear - I
(hopefully correctly) understand it is needed here since the "user-defined way"
described in NOTE 8.41 does *not* imply the one way ordering enforced by
the semantics of LOCK.

> 
> Regards,
> Nick Maclaren.
> 
> 
> 

Thanks
Reinhold