Re: better atomics - v0.2 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: better atomics - v0.2
Date
Msg-id 20131115200416.GH5489@awork2.anarazel.de
Whole thread Raw
In response to better atomics  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: better atomics - v0.2  (Robert Haas <robertmhaas@gmail.com>)
Re: better atomics - v0.2  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: additional json functionality
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_dump insert with column names speedup