Re: better atomics - Mailing list pgsql-hackers

On Mon, Oct 28, 2013 at 2:19 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> I'm not terribly excited about relying on 16-byte CAS, but I agree
>> that 8-byte math, at least, is important.  I've not been successful in
>> finding any evidence that gcc has preprocessor symbols to tell us
>> about the properties of 8-byte loads and stores.  The closest thing
>> that I found is:
>
> I am talking about making 16byte CAS explicitly optional though? I think
> if code wants to optionally make use of it (e.g. on x86 where it's been
> available basically forever) that's fine. It just has to be optional.
> Or are you saying you're simply not interested in 16byte CAS generally?

I am just not interested in it generally.  Relying on too many OS or
architecture-specific primitives has several disadvantages.  It's
going to be a nuisance on more obscure platforms where they may or may
not be supported and may or may not work right even if supported.
Even once we get things working right everywhere, it'll mean that
performance may suffer on non-mainstream platforms.  And I think in
many cases it may suggest that we're using an architecture-specific
quirk to work around a fundamental problem with our algorithms.  I'm
more or less convinced of the need for 8-byte atomic reads and writes,
test-and-set, 8-byte compare-and-swap, and 8-byte fetch-and-add.  But
beyond that I'm less sold.  Most of the academic papers I've read on
implementing lock-free or highly-parallel constructs attempt to
confine themselves to 8-byte operations with 8-byte compare-and-swap,
and I'm a bit disposed to think we ought to try to hew to that as
well.  I'm not dead set against going further, but I lean against it,
for all of the reasons mentioned above.

> Same thing for 8byte math - there's no chance that that is going to be
> supported over all platforms anytime soon, so it has to be optional.

Agreed.

>> http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
>>
>> That page provides intrinsics for 8-byte atomic loads and stores,
>> among other things.  But it seems that the only method for determining
>> whether they work on a particular target is to compile a test program
>> and see whether it complains about __atomic_load_n and/or
>> __atomic_store_n being unresolved symbols.  I suppose we could add a
>> configure test for that.  Yuck.
>
> Well, that's pretty easy to integrate into configure - and works on
> crossbuilds. So I think that'd be ok.
>
> But I actually think this is going to be a manual thing, atomic 8byte
> math will fall back to kernel emulation on several targets, so we
> probably want some defines to explicitly declare it supported on targets
> where that's not the case.

Hmm, OK.  I had not come across such cases.  There are architectures
where it Just Works (like x64_64), architectures where you can make it
work by using special instructions (like x86), and (presumably)
architectures where it doesn't work at all.  Places where it works
using really slow kernel emulation are yet another category to worry
about.  Unfortunately, I have not found any good source that describes
which architectures fall into which category.  Without that, pulling
this together seems intimidating, unless we just declare it working
for x86_64, disable it everywhere else, and wait for people running on
other architectures to complain.

I wonder whether it'd be safe to assume that any machine where
pointers are 8 bytes has 8-byte atomic loads and stores.  I bet there
is a counterexample somewhere.  :-(

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company