From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 14:30:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A90F416A420; Tue, 6 Dec 2005 14:30:53 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0949543D5E; Tue, 6 Dec 2005 14:30:41 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by kane.otenet.gr (8.13.4/8.13.4/Debian-8) with SMTP id jB6EUXDE012374; Tue, 6 Dec 2005 16:30:34 +0200 Received: by flame.pc (Postfix, from userid 1001) id 98A3F117BE; Tue, 6 Dec 2005 16:29:50 +0200 (EET) Date: Tue, 6 Dec 2005 16:29:50 +0200 From: Giorgos Keramidas To: Fredrik Lindberg Message-ID: <20051206142950.GA14331@flame.pc> References: <43938F61.1050202@terranova.net> <4393F60E.2040106@shapeshifter.se> <86mzjflc97.fsf@xps.des.no> <439495B1.5060305@shapeshifter.se> <861x0qmuen.fsf@xps.des.no> <43956ADF.4050504@shapeshifter.se> <86slt6lb9s.fsf@xps.des.no> <43958F9A.2000205@shapeshifter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43958F9A.2000205@shapeshifter.se> Cc: Dag-Erling Sm?rgrav , Travis Mikalson , current@freebsd.org, njl@freebsd.org Subject: Re: powerd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2005 14:30:53 -0000 On 2005-12-06 14:18, Fredrik Lindberg wrote: >Dag-Erling Sm?rgrav wrote: >>Fredrik Lindberg writes: >>>Dag-Erling Sm?rgrav wrote: >>>> If the devd loop is an *alternative* to the polling loop, there's >>>> even less reason to use threads. >>> >>> Yes it's an alternative, reading a variable versus doing a sysctl call >>> each interation. It seemed like I good idea, when I first wrote this >>> (almost a year ago), to have a thread providing a cached value of the >>> AC state. But maybe I was trying to be too smart or something. >> >> Yes. Not only is it a bad design idea, but the implementation is >> wrong, and likely to fail badly when compiled at high optimization >> levels. > > Ignoring the fact that it does work with -O3 (gcc 3.4.4), could you > please explain why it has the potential of failing with high > optimizations. I haven't looked at the source code, but I think what Dag-Erling means is that optimizing compilers, in high optimization mode, may inhibit sequential read operations of the same variable, trying to 'optimize' many read operations that would (to the best of their knowledge) return the same result. This is never going to happen if the variable is declared as 'volatile' though, so I'm not sure if it applies in this case, until I look at the sources of powerd. - Giorgos