From dev-return-21838-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Jun 10 01:01:09 2009 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 96983 invoked from network); 10 Jun 2009 01:01:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Jun 2009 01:01:09 -0000 Received: (qmail 38237 invoked by uid 500); 10 Jun 2009 01:01:20 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 38157 invoked by uid 500); 10 Jun 2009 01:01:20 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 38149 invoked by uid 99); 10 Jun 2009 01:01:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jun 2009 01:01:20 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.202.165.38] (HELO smtpauth21.prod.mesa1.secureserver.net) (64.202.165.38) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 10 Jun 2009 01:01:11 +0000 Received: (qmail 3000 invoked from network); 10 Jun 2009 01:00:47 -0000 Received: from unknown (76.252.112.72) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 10 Jun 2009 01:00:47 -0000 Message-ID: <4A2F05B5.4000503@rowe-clan.net> Date: Tue, 09 Jun 2009 20:00:37 -0500 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Bojan Smojver CC: dev@apr.apache.org Subject: Re: [MAINTAINER] devel/apr-gdbm-db42: apr-util 1.3.7 breaks dbd support References: <200906090316.n593GCYQ075516@frieza.p6m7g8.net> <1244520824.25532.88.camel@shrek.rexursive.com> <4A2DF79D.709@rowe-clan.net> <4A2E001E.4020806@p6m7g8.com> <1244531713.25532.95.camel@shrek.rexursive.com> <4A2E0CB8.1090701@p6m7g8.com> <1244532560.25532.103.camel@shrek.rexursive.com> <1244534466.25532.113.camel@shrek.rexursive.com> <4A2E6BA4.7040305@rowe-clan.net> <20090609152157.GA15723@redhat.com> <4A2E86A0.5080005@rowe-clan.net> <1244595226.25532.146.camel@shrek.rexursive.com> In-Reply-To: <1244595226.25532.146.camel@shrek.rexursive.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Bojan Smojver wrote: > On Tue, 2009-06-09 at 10:58 -0500, William A. Rowe, Jr. wrote: >> You are not missing anything, and solutions are welcomed. > > I'm not sure that I'm addressing the right problem here. So, limit > yourself to rocks of no more than 2kg when throwing. :) > Obviously, there is no guarantee that int's are atomic, so this patch > as-is is bogus. However, we have an atomic API in APR, so we can replace > the int's with apr_uint32_t, use that API to increment/decrement the > variables and also initialise it from apr_initialize() function, which > would then make sure it is available. > > Complete nonsense? No; this looks to be a very reasonable solution, depending on n++ is implemented in assembly code. Also remember in smp you might have two cpus potentially executing the code in lockstep. That said, this looks to significantly narrow the race, so +1 for 1.x!