From owner-sc22wg5@open-std.org  Wed Apr 21 23:18:46 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 F2844C4EA18; Wed, 21 Apr 2010 23:18:45 +0200 (CET DST)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from mailrelay1.lrz-muenchen.de (mailrelay1.lrz-muenchen.de [129.187.254.106])
	by www2.open-std.org (Postfix) with ESMTP id 664BCC4E9FA
	for <sc22wg5@open-std.org>; Wed, 21 Apr 2010 23:18:44 +0200 (CET DST)
Received: from [129.187.48.222] ([129.187.48.222] [129.187.48.222]) by mailout.lrz-muenchen.de with ESMTP for sc22wg5@open-std.org; Wed, 21 Apr 2010 23:18:23 +0200
Message-Id: <4BCF6B9F.4000800@lrz.de>
Date: Wed, 21 Apr 2010 23:18:23 +0200
From: Reinhold Bader <Reinhold.Bader@lrz.de>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Cc: WG5 <sc22wg5@open-std.org>
Subject: Re: (SC22WG5.4253) (j3.2006) Question on locks
References: <20100421204947.D8CC7C178DA@www2.open-std.org> <20100421211033.11C11C4E9FA@www2.open-std.org>
In-Reply-To: <20100421211033.11C11C4E9FA@www2.open-std.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

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.

> Aleks
>
> On Wednesday 21 April 2010, Reinhold Bader wrote:
>   
>> Does this not imply that in certain situations it may be necessary to
>> explicitly execute a
>> SYNC MEMORY after successfully acquiring a lock? In particular, is
>> not such a statement
>> required immediately after the statement
>>
>> LOCK(queue_lock)  ! New segment A starts
>>
>> in Note 8.45 since otherwise a register-stored value of
>> work_queue_size might be used,
>> overlooking the update of its memory location by a remote image?
>>     
>
>
>