Re: better atomics - Mailing list pgsql-hackers

From Robert Haas
Subject Re: better atomics
Date
Msg-id CA+TgmoYyBN_wbwfs0WVG6Tc0UC7uLVNoVmCTnFm9ejEMYdt7BQ@mail.gmail.com
Whole thread Raw
In response to better atomics  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: better atomics
List pgsql-hackers
On Wed, Oct 16, 2013 at 12:52 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> I have a related problem, which is that some code I'm currently
>> working on vis-a-vis parallelism can run lock-free on platforms with
>> atomic 8 bit assignment but needs a spinlock or two elsewhere.  So I'd
>> want to use pg_atomic_store_u64(), but I'd also need a clean way to
>> test, at compile time, whether it's available.
>
> Yes, definitely. There should be a couple of #defines that declare
> whether non-prerequisite options are supported. I'd guess we want at least:
> * 8byte math
> * 16byte compare_and_swap

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:

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.

Anyone have a better idea?

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Detection of nested function calls
Next
From: Tom Lane
Date:
Subject: Re: OSX doesn't accept identical source/target for strcpy() anymore