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

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

  1. Avoid the use of a separate spinlock to protect a LWLock's wait queue.

  2. Improve LWLock scalability.

  3. Reduce the number of semaphores used under --disable-spinlocks.

  4. Alter the configure script to fail immediately if the C compiler does not