From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Ants Aasma <ants(at)cybertec(dot)at> |
Subject: | Re: better atomics - v0.2 |
Date: | 2013-11-15 20:04:16 |
Message-ID: | 20131115200416.GH5489@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
0001-Try-to-make-HP-UX-s-ac-not-cause-warnings-about-unus.patch | text/x-patch | 723 bytes |
0002-Very-basic-atomic-ops-implementation.patch | text/x-patch | 98.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-11-15 20:04:37 | Re: pg_dump insert with column names speedup |
Previous Message | David E. Wheeler | 2013-11-15 19:51:50 | Re: additional json functionality |