Re: better atomics - v0.2
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@heroku.com>,
Pg Hackers <pgsql-hackers@postgresql.org>, Ants Aasma <ants@cybertec.at>
Date: 2013-11-19T15:27:57Z
Lists: pgsql-hackers
On Tue, Nov 19, 2013 at 10:26 AM, Andres Freund <andres@2ndquadrant.com> wrote: > 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. Sure, but if people can't understand the API, then it's hard to decide whether to be unhappy with it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Avoid the use of a separate spinlock to protect a LWLock's wait queue.
- 008608b9d510 9.6.0 cited
-
Improve LWLock scalability.
- ab5194e6f617 9.5.0 cited
-
Reduce the number of semaphores used under --disable-spinlocks.
- daa7527afc22 9.4.0 cited
-
Alter the configure script to fail immediately if the C compiler does not
- d15cb38dec01 9.0.0 cited