From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8089 invoked by alias); 29 Oct 2007 03:08:48 -0000 Received: (qmail 8080 invoked by uid 22791); 29 Oct 2007 03:08:47 -0000 X-Spam-Check-By: sourceware.org Received: from ipmail03.adl2.internode.on.net (HELO ipmail03.adl2.internode.on.net) (203.16.214.135) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 29 Oct 2007 03:08:45 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAH/qJEd5LGK+/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.21,339,1188743400"; d="scan'208";a="176618039" Received: from ppp121-44-98-190.lns10.syd6.internode.on.net (HELO [192.168.1.201]) ([121.44.98.190]) by ipmail03.adl2.internode.on.net with ESMTP; 29 Oct 2007 13:37:44 +1030 Subject: Re: Optimization of conditional access to globals: thread-unsafe? From: skaller To: Bart Van Assche Cc: Robert Dewar , Florian Weimer , Andrew Haley , gcc@gcc.gnu.org, Andrew Pinski , Tomash Brechko In-Reply-To: References: <18210.795.425145.46885@zebedee.pink> <87hckcpvp5.fsf@mid.deneb.enyo.de> <87abq4ofym.fsf@mid.deneb.enyo.de> <472492F8.90700@adacore.com> Content-Type: text/plain Date: Mon, 29 Oct 2007 03:19:00 -0000 Message-Id: <1193627263.3963.93.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 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: 2007-10/txt/msg00654.txt.bz2 On Sun, 2007-10-28 at 21:43 +0100, Bart Van Assche wrote: > On 10/28/07, Robert Dewar wrote: > > Bart Van Assche wrote: > > > > > My opinion is that, given the importance of multithreading, it should > > > be documented in the gcc manual which optimizations can cause trouble > > > in multithreaded software (such as (3) and (4)). It should also be > > > documented which compiler flags must be used to disable optimizations > > > that cause trouble for multithreaded software. Requiring that all > > > thread-shared variables should be declared volatile is completely > > > unacceptable. > > > > Why is this unacceptable .. seems much better to me than writing > > undefined stuff. > > Requiring that all thread-shared variables must be declared volatile, > even those protected by calls to synchronization functions, implies > that all multithreaded code and all existing libraries have to be > changed. Yes, of course that is out of the question. Instead all shared variables are treated as sharable. This is NOT the same as volatile. Sharable variables need to be 'de-registered' (dumped out of aliasing registers) at function call boundaries. This is MUCH less strict than volatile, which is at every sequence point. If the function call is to a visible function, gcc can look in it to see if it might fiddle a mutex, and if not, there's no need to dump the registers. In particular, there's no synchronisation point when a function is inlined. IMHO the effect of this is to change the optimiser so that local variables not addressed are preferred for lifting to registers over globals or addressed locals. C++ non-static members must be treated as sharable, even if they're private, however this is not necessarily a big deal if they're inline. The effect seems to be that this: if(cond)x++; can quite safely be replaced by r0 <- x; if(cond) r0++; x <- r0; which is the topic of this discussion. If this code mutually excludes other accesses to x, then it is safe, and if it doesn't, then the programmer is responsible for writing undefined behaviour, not the compiler. -- John Skaller Felix, successor to C++: http://felix.sf.net