Re: better atomics - v0.5 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: better atomics - v0.5
Date
Msg-id 20140630201604.GN21422@awork2.anarazel.de
Whole thread Raw
In response to Re: better atomics - v0.5  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-06-30 13:45:52 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I'm personally not convinced that we're approaching this topic in the
> > right way.  I'm not convinced that it's at all reasonable to try to
> > emulate atomics on platforms that don't have them.  I would punt the
> > problem into the next layer and force things like lwlock.c to have
> > fallback implementations at that level that don't require atomics, and
> > remove those fallback implementations if and when we move the
> > goalposts so that all supported platforms must have working atomics
> > implementations.  People who write code that uses atomics are not
> > likely to think about how those algorithms will actually perform when
> > those atomics are merely emulated, and I suspect that means that in
> > practice platforms that have only emulated atomics are going to
> > regress significantly vs. the status quo today.
> 
> I think this is a valid objection, and I for one am not prepared to
> say that we no longer care about platforms that don't have atomic ops
> (especially not if it's not a *very small* set of atomic ops).

It's still TAS(), cmpxchg(), xadd. With TAS/xadd possibly implemented
via cmpxchg (which quite possibly *is* the native implementation for
$arch).

> Also, just because a platform claims to have atomic ops doesn't mean that
> those ops perform well.  If there's a kernel trap involved, they don't,
> at least not for our purposes.

Yea. I think if we start to use 8byte atomics at some later point we're
going to have to prohibit e.g. older arms from using them, even if the
compiler claims they're supported. But that's just one #define.

> This is one
> reason why I'm extremely suspicious of depending on gcc's intrinsics for
> this; that will not make the issue go away, only make it beyond our
> power to control.

The patch as submitted makes it easy to provide a platform specific
implementation of the important routines if it's likely that it's better
than the intrinsics provided one.

I'm not too worried about the intrinsics though - the number of projects
relying on them these days is quite large.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: PATCH: Allow empty targets in unaccent dictionary
Next
From: Noah Misch
Date:
Subject: Re: PostgreSQL in Windows console and Ctrl-C