Re: xlc atomics
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@heroku.com>, Ants Aasma <ants@cybertec.at>
Date: 2016-04-27T02:04:33Z
Lists: pgsql-hackers
On Mon, Apr 25, 2016 at 11:52:04AM -0700, Andres Freund wrote: > On 2016-04-23 21:54:07 -0400, Noah Misch wrote: > > The bug is that the pg_atomic_compare_exchange_*() specifications > > grant "full barrier semantics", but generic-xlc.h provided only the > > semantics of an acquire barrier. > > I find the docs at > http://www-01.ibm.com/support/knowledgecenter/SSGH3R_13.1.2/com.ibm.xlcpp131.aix.doc/compiler_ref/bifs_sync_atomic.html > to be be awfully silent about that matter. I guess you just looked at > the assembler code? It's nice that one can figure out stuff like that > from an architecture manual, but it's sad that the docs for the > intrinsics is silent about that matter. Right. The intrinsics provide little value as abstractions if one checks the generated code to deduce how to use them. I was tempted to replace the intrinsics calls with inline asm. At least these functions are unlikely to change over time. > Except that I didn't verify the rs6000_pre_atomic_barrier() and > __fetch_and_add() internals about emitted sync/isync, the patch looks > good. We've so far not referred to "sequential consistency", but given > it's rise in popularity, I don't think it hurts. Thanks; committed.
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