Date: Mon, 30 Jun 2014 22:16:04 +0200
From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@heroku.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>, Ants Aasma <ants@cybertec.at>
Subject: Re: better atomics - v0.5
Message-ID: <20140630201604.GN21422@awork2.anarazel.de>
References: <54412.1403808435@sss.pgh.pa.us>
 <20140626190405.GA21422@awork2.anarazel.de>
 <CA+TgmoZjAiqjg40364uSkyh8c7iib_VbvsTDuwG2d-rX8p1BeA@mail.gmail.com>
 <20140627180033.GF18288@awork2.anarazel.de>
 <CA+TgmoZBnU7UcDRw1_Mgu3nW3RQ1OeSGecO_--Br7f5gz0GUrA@mail.gmail.com>
 <20140628082559.GB6450@awork2.anarazel.de>
 <CA+TgmoYd1BKsbvqPuCQuQb6+9znVLgjhJTvLo9tS=FuY1jXw0Q@mail.gmail.com>
 <11914.1404147250@sss.pgh.pa.us>
 <CA+TgmobLpKZU0TWOmg8kGFBjhszxiexQpDEmcUBm10-1eLZgUg@mail.gmail.com>
 <12903.1404150352@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <12903.1404150352@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers