From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23970 invoked by alias); 26 Oct 2007 23:25:20 -0000 Received: (qmail 23957 invoked by uid 22791); 26 Oct 2007 23:25:19 -0000 X-Spam-Check-By: sourceware.org Received: from ipmail01.adl2.internode.on.net (HELO ipmail01.adl2.internode.on.net) (203.16.214.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Oct 2007 23:25:18 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMISIkd5LCRsWmdsb2JhbAAMjkoBIA X-IronPort-AV: E=Sophos;i="4.21,335,1188743400"; d="scan'208";a="219624362" Received: from ppp121-44-36-108.lns10.syd7.internode.on.net (HELO [192.168.1.201]) ([121.44.36.108]) by ipmail01.adl2.internode.on.net with ESMTP; 27 Oct 2007 08:55:15 +0930 Subject: Re: Optimization of conditional access to globals: thread-unsafe? From: skaller To: Tomash Brechko Cc: gcc@gcc.gnu.org In-Reply-To: <20071026190312.GF5041@moonlight.home> References: <20071026143334.GA5041@moonlight.home> <20071026155101.GB5041@moonlight.home> <016201c817e9$5454edd0$2e08a8c0@CAM.ARTIMI.COM> <20071026161739.GC5041@moonlight.home> <1193418381.15346.2.camel@rosella.wigram> <20071026190312.GF5041@moonlight.home> Content-Type: text/plain Date: Fri, 26 Oct 2007 23:34:00 -0000 Message-Id: <1193441109.15346.63.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/msg00560.txt.bz2 On Fri, 2007-10-26 at 23:03 +0400, Tomash Brechko wrote: > On Sat, Oct 27, 2007 at 03:06:21 +1000, skaller wrote: > > And what do you do if you do not KNOW what the storage class is, > > which is the case 99.99% of the time in C++ member functions? > > I'm not quite sure what you mean here. If extern vs static---that's > of no concern. What matters is whether the object can possibly be > accessed from another thread, and this has nothing specific to C++. Yes, but with a class: struct X { int x; void f() { if (C) x = 1; } void f2() { reg = x; if (c) reg = 1; x = reg; } }; X global; void k() { X local; global.f(); global.f2(); local.f(); local.f2(); }; you would have to assume all member variables were accessible to another thread when generating the member functions, even if the variable is private, unless you did heavy analysis to ensure the class didn't leak its address. In effect this means method access is slower than global functions in a threading context.** [** in Felix I attempt to generate a global function instead of a class for a Felix function, which is a C++ applicative object .. but then Felix is a whole program analyser so it can do this. The reason is .. that I guessed C++ compilers such as gcc optimise global functions better than methods.] -- John Skaller Felix, successor to C++: http://felix.sf.net