Re: better atomics - v0.2
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.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-15T20:04:16Z
Lists: pgsql-hackers
Attachments
- 0001-Try-to-make-HP-UX-s-ac-not-cause-warnings-about-unus.patch (text/x-patch) patch 0001
- 0002-Very-basic-atomic-ops-implementation.patch (text/x-patch) patch 0002
Hi, This is the first real submission of how I think our atomics architecture should look like. It's definitely a good bit from complete, please view it from that POV! The most important thing I need at this point is feedback whether the API in general looks ok and what should be changed, before I spend the time to implement it nicely everywhere. The API is loosely modeled to match C11's atomics http://en.cppreference.com/w/c/atomic library, at least to the degree that the latter could be used to implement pg's atomics. Please note: * Only gcc's implementation is tested. I'd be really surprised if it compiled on anything else. * I've currently replaced nearly all of s_lock.h to use parts of the atomics API. We might rather use it's contents to implement atomics 'flags' on some of the wierder platforms out there. * I've integrated barrier.h into the atomics code. It's pretty much a required part, and compiler/arch specific so that seems to make sense. * 'autoreconf' needs to be run after applying the patchset. I got some problems with running autoconf 2.63 here, using 2.69 makes the diff to big. Questions: * What do you like/dislike about the API (storage/atomics.h) * decide whether it's ok to rely on inline functions or whether we need to provide out-of-line versions. I think we should just bite the bullet and require support. Some very old arches might need to live with warnings. Patch 01 tries to silence them on HP-UX. * decide whether we want to keep the semaphore fallback for spinlocks. I strongly vote for removing it. The patchset provides compiler based default implementations for atomics, so it's unlikely to be helpful when bringing up a new platform. TODO: * actually test on other platforms that new gcc * We should probably move most of the (documentation) content of s_lock.h somewhere else. * Integrate the spinlocks based fallback for platforms that only provide something like TAS(). Comments? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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