Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VinBq-0001ce-B6 for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Nov 2013 15:26:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VinBp-0007z6-RF for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Nov 2013 15:26:09 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VinBo-0007yy-KR for pgsql-hackers@postgresql.org; Tue, 19 Nov 2013 15:26:08 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VinBi-0007Rj-6c for pgsql-hackers@postgresql.org; Tue, 19 Nov 2013 15:26:08 +0000 Received: from intern.anarazel.de (p5DDC736E.dip0.t-ipconnect.de [93.220.115.110]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id F14F14F0001; Tue, 19 Nov 2013 16:26:00 +0100 (CET) Date: Tue, 19 Nov 2013 16:26:00 +0100 From: Andres Freund To: Robert Haas Cc: Tom Lane , Peter Geoghegan , Pg Hackers , Ants Aasma Subject: Re: better atomics - v0.2 Message-ID: <20131119152600.GA18094@alap2.anarazel.de> References: <20131115200416.GH5489@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 2013-11-19 09:12:42 -0500, Robert Haas wrote: > On point #1, I dunno. It looks like a lot of rearrangement to me, and > I'm not really sure what the final form of it is intended to be. Understandable. I am not that sure what parts we want to rearange either. We very well could leave barrier.h and s_lock.h untouched and just maintain the atomics stuff in parallel and switch over at some later point. I've mainly switched over s_lock.h to a) get some good coverage of the atomics code b) make sure the api works fine for it. We could add the atomics.h based implementation as a fallback for the cases in which no native implementation is available. > I think it desperately needs a README explaining what the point of all > this is and how to add support for a new platform or compiler if yours > doesn't work. Ok, I'll work on that. It would be useful to get feedback on the "frontend" API in atomics.h though. If people are unhappy with the API it might very well change how we can implement the API on different architectures. 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