Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X097g-0001gv-Ny for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jun 2014 12:49:52 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X097g-0002OF-37 for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jun 2014 12:49:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X097e-0002O7-ME for pgsql-hackers@postgresql.org; Thu, 26 Jun 2014 12:49:50 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X097b-00015A-At for pgsql-hackers@postgresql.org; Thu, 26 Jun 2014 12:49:49 +0000 Received: by mail.anarazel.de (Postfix, from userid 108) id 48491520005; Thu, 26 Jun 2014 14:49:46 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail X-Spam-Level: X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from anarazel.de (p5DDC5C48.dip0.t-ipconnect.de [93.220.92.72]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id 00FDF520004; Thu, 26 Jun 2014 14:49:43 +0200 (CEST) Received: by anarazel.de (Postfix, from userid 1000) id 887F610037B; Thu, 26 Jun 2014 14:49:42 +0200 (CEST) Date: Thu, 26 Jun 2014 14:49:42 +0200 From: Andres Freund To: Merlin Moncure Cc: Robert Haas , Tom Lane , Peter Geoghegan , Pg Hackers , Ants Aasma Subject: Re: better atomics - v0.5 Message-ID: <20140626124942.GD1926@awork2.anarazel.de> References: <20140625171434.GG24114@awork2.anarazel.de> <20140625203635.GJ24114@awork2.anarazel.de> <20140626102006.GB1926@awork2.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2014-06-26 07:44:14 -0500, Merlin Moncure wrote: > On Thu, Jun 26, 2014 at 5:20 AM, Andres Freund wrote: > > On 2014-06-25 20:16:08 -0400, Robert Haas wrote: > >> On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund wrote: > >> > Since it better be legal to manipulate a atomic variable while holding a > >> > spinlock we cannot simply use an arbitrary spinlock as backing for > >> > atomics. That'd possibly cause us to wait on ourselves or cause > >> > deadlocks. > >> > >> I think that's going to fall afoul of Tom's previously-articulated "no > >> loops inside spinlocks" rule. Most atomics, by nature, are > >> loop-until-it-works. > > > > Well, so is TAS itself :). > > > > More seriously, I think we're not going to have much fun if we're making > > up the rule that you can't do an atomic add/sub while a spinlock is > > held. That just precludes to many use cases and will make the code much > > harder to understand. I don't think we're going to end up having many > > problems if we allow atomic read/add/sub/write in there. > > That rule seems reasonable -- why would you ever want to do this? Are you wondering why you'd ever manipulate an atomic op inside a spinlock? There's enough algorithms where a slowpath is done under a spinlock but the fastpath is done without. You can't simply use nonatomic operations for manipulation under the spinlock because the fastpaths might then observe/cause bogus state. Obviously I'm not advocating to do random stuff in spinlocks. W're talking about single lock xadd;s (or the LL/SC) equivalent here. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers