From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8961 invoked by alias); 6 Sep 2008 09:26:06 -0000 Received: (qmail 8943 invoked by uid 22791); 6 Sep 2008 09:26:04 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Sep 2008 09:25:26 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m869POo3017942; Sat, 6 Sep 2008 05:25:24 -0400 Received: from zebedee.pink (vpn-12-4.rdu.redhat.com [10.11.12.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m869PMff006540; Sat, 6 Sep 2008 05:25:23 -0400 Message-ID: <48C24C82.9030602@redhat.com> Date: Mon, 08 Sep 2008 17:42:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Hans Boehm CC: Java Patch List Subject: Re: Remove data race in libgcj interpreter References: <48AD67B2.4040308@redhat.com> <48C0042C.5080804@redhat.com> <238A96A773B3934685A7269CC8A8D0423152AF178E@GVW0436EXB.americas.hpqcorp.net> <48C0FE20.2020103@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00080.txt.bz2 Hans Boehm wrote: > > > 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. Indeed. The solution of detecting the case where two threads are concurrently executing a method seems far the best: it's obviously correct without requiring deep analysis of memory behaviour. I'm investigating that. Andrew.