From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4607 invoked by alias); 6 Sep 2008 05:04:47 -0000 Received: (qmail 4354 invoked by uid 22791); 6 Sep 2008 05:04:45 -0000 X-Spam-Check-By: sourceware.org Received: from g1t0029.austin.hp.com (HELO g1t0029.austin.hp.com) (15.216.28.36) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Sep 2008 05:04:02 +0000 Received: from mailstation.cce.hp.com (mailstation.zcce.gate.cpqcorp.net [16.104.192.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTP id DDDCB38053; Sat, 6 Sep 2008 05:04:00 +0000 (UTC) Received: from eeepc-hansboehm (m208-135.dsl.rawbw.com [198.144.208.135]) by mailstation.cce.hp.com (Postfix) with ESMTP id D9DD0C027; Sat, 6 Sep 2008 00:03:59 -0500 (CDT) Date: Sat, 06 Sep 2008 09:26:00 -0000 From: Hans Boehm To: Andrew Haley Cc: "Boehm, Hans" , Java Patch List Subject: Re: Remove data race in libgcj interpreter In-Reply-To: <48C0FE20.2020103@redhat.com> Message-ID: References: <48AD67B2.4040308@redhat.com> <48C0042C.5080804@redhat.com> <238A96A773B3934685A7269CC8A8D0423152AF178E@GVW0436EXB.americas.hpqcorp.net> <48C0FE20.2020103@redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2008-q3/txt/msg00079.txt.bz2 On Fri, 5 Sep 2008, Andrew Haley wrote: > You're right, I was assuming exactly that. OK, but that is presumably > simply a lack of volatility in the declaration of PC. As a practical matter, that would probably help at the expense of slowing things down a bit on some architectures. Officially this doesn't help much, since I believe Posix allows undefined behavior for data races, even if they involve volatiles. Even in terms of current implementations, I don't believe it prevents hardware reordering on architectures like PowerPC. The C++ working paper provides atomic operations to address these issues. I think they're even somewhat implemented in the gcc trunk. But I'm not sure you can avoid operations that generate fences on some architectures in what should be the fast path. Hans