On 2013-10-28 14:10:48 -0400, Robert Haas wrote:
> 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:
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?
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.
> 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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
