From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16056 invoked by alias); 5 Oct 2011 12:49:42 -0000 Received: (qmail 16043 invoked by uid 22791); 5 Oct 2011 12:49:41 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Oct 2011 12:49:25 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p95CnPj1018186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Oct 2011 08:49:25 -0400 Received: from [10.11.11.228] (vpn-11-228.rdu.redhat.com [10.11.11.228]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p95CnNn4023902; Wed, 5 Oct 2011 08:49:24 -0400 Message-ID: <4E8C5253.5040105@redhat.com> Date: Wed, 05 Oct 2011 18:58:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc13 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jeffrey Yasskin CC: Lawrence Crowl , Benjamin Kosnik , Richard Henderson , Aldy Hernandez , GCC Subject: Re: C++11 atomic library notes References: <4E862864.2010607@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00074.txt.bz2 On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote: > > If, as the document proposes, "16 byte volatile will have to call the > external rotines, but 16 byte non-volatiles would be lock-free.", and > the external routines use locked accesses for 16-byte volatile > atomics, then this makes the concurrent accesses to shared_var not > thread-safe. To be thread-safe, we'd have to call the external > routines for every 16-byte atomic, not just the volatile ones, and > those routines would have to use locked accesses uniformly rather than > distinguishing between volatile and non-volatile accesses. Not good. > This would seem to support that an object of a given size must be consistent, and that volatility is not a basis to segregate behaviour. Which is good because thats the result I want but was concerned about :-) > Even worse, on LL/SC architectures, every lock-free RMW operation > potentially involves multiple loads, so this interpretation of > volatility would prohibit lock-free access to all objects. > > I see two ways out: > 1) Say that accessing a non-volatile atomic through a volatile > reference or pointer causes undefined behavior. The standard doesn't > say that, and the casts are implicit, so this is icky. > 2) Say that volatile atomic accesses may be implemented with more than > one instruction-level access. > > (2) is something like how volatile reads of 128-bit structs involve > multiple mov instructions that execute in an arbitrary order. It's > also unlikely to cause problems in existing programs because nobody's > using volatile atomics yet, and they'll only start using them in ways > that work with what compilers implement. To clarify, you are suggesting that we say atomic accesses to volatile objects may involve more than a single load? Can we also state that a 'harmless' store may also happen? (ie, a 0 to an existing 0, or some other arbitrary value) Otherwise I don't know how to get a 128 bit atomic load on x86-64 :-P which then means no inlined lock-free atomics on 16 byte values. Its unpleasant, but... other suggestions? Andrew