On 2016-04-23 21:54:07 -0400, Noah Misch wrote:
> I missed a second synchronization bug in generic-xlc.h, but the pgbench test
> suite caught it promptly after commit 008608b.
Nice catch.
> 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.
I do wonder if I shouldn't have left xlc fall by the wayside, and make
it use the fallback implementation. Given it's popularity (or rather
lack thereof) that'd probably have been a better choice. But that ship
has sailed.
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.
Stricly speaking generic-xlc.c shouldn't contain inline-asm, but given
xlc is only there for power...
Greetings,
Andres Freund
