Re: better atomics

On 2013-10-28 15:02:41 -0400, Robert Haas wrote:
> On Mon, Oct 28, 2013 at 2:19 PM, Andres Freund <andres(at)2ndquadrant(dot)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.

But it'll suffer against the *increased* performance on modern
platforms, it shouldn't suffer noticeably against the previous
performance on the older platform if we're doing our homework...

> 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.

I think there are quite some algorithms relying on 16byte CAS, that's
why I was thinking about it at all. I think it's easier to add support
for it in the easier trawl through the compilers, but I won't argue much
for it otherwise for now.

> > 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.

E.g. ARM/linux which we probably cannot ignore.

> 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.

Yes, I think whitelisting targs is a sensible approach here. I am pretty
sure we can do better than just x86-64, but that's easily doable in an
incremental fashion.

> 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. :-(

Sparc64 :(.

Btw, could you quickly give some keywords what you're thinking about
making lockless?
I mainly am thinking about lwlocks and buffer pins so far. Nothing
really ambitious.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services