From owner-sc22wg5@open-std.org  Thu Apr 22 09:31:27 2010
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id CC464C3BA2A; Thu, 22 Apr 2010 09:31:27 +0200 (CET DST)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from mailrelay2.lrz-muenchen.de (mailrelay2.lrz-muenchen.de [129.187.254.102])
	by www2.open-std.org (Postfix) with ESMTP id 3A05CC178D9
	for <sc22wg5@open-std.org>; Thu, 22 Apr 2010 09:31:26 +0200 (CET DST)
Received: from [129.187.15.179] ([129.187.15.179] [129.187.15.179]) by mailout.lrz-muenchen.de with ESMTP for sc22wg5@open-std.org; Thu, 22 Apr 2010 09:31:05 +0200
Message-Id: <4BCFFB39.7040802@lrz.de>
Date: Thu, 22 Apr 2010 09:31:05 +0200
From: Reinhold Bader <Reinhold.Bader@lrz.de>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
Cc: WG5 <sc22wg5@open-std.org>
Subject: Re: (SC22WG5.4255) [ukfortran] (j3.2006) Question on locks
References: <20100421204947.D8CC7C178DA@www2.open-std.org> <20100421211033.11C11C4E9FA@www2.open-std.org> <20100421211846.2761BC4E9FA@www2.open-std.org> <20100421221958.90A94C4E9FA@www2.open-std.org>
In-Reply-To: <20100421221958.90A94C4E9FA@www2.open-std.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

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