On 09/24/2014 07:57 PM, Andres Freund wrote:
On 2014-09-24 12:44:09 -0400, Tom Lane wrote:
Andres Freund <and...@2ndquadrant.com> writes:
On 2014-09-24 18:55:51 +0300, Heikki Linnakangas wrote:
There doesn't seem to be any hardware implementations of that in the patch.
Is there any architecture that has an instruction or compiler intrinsic for
that?
You can implement it rather efficiently on ll/sc architectures. But I
don't really think it matters. I prefer add_until (I've seen it named
saturated add before as well) to live in the atomics code, rather than
reimplement it in atomics employing code. I guess you see that
differently?
I think the question is more like "what in the world happened to confining
ourselves to a small set of atomics".
I fail to see why the existance of a wrapper around compare-exchange
(which is one of the primitives we'd agreed upon) runs counter to
the agreement that we'll only rely on a limited number of atomics on the
hardware level?
It might be a useful function, but if there's no hardware implementation
for it, it doesn't belong in atomics.h. We don't want to turn it into a
general library of useful little functions.
I doubt either that this exists
natively anywhere, or ethat it's so useful that we should expect platforms
to have efficient implementations.
Googling around, ARM seems to have a QADD instruction that does that.
But AFAICS it's not an atomic instruction that you could use for
synchronization purposes, just a regular instruction.
It's useful for my work to get rid of most LockBufHdr() calls (to
manipulate usagecount locklessly). That's why I added it. We can delay
it till that patch is ready, but I don't really see the benefit.
Yeah, please leave it out for now, we can argue about it later. Even if
we want it in the future, it would be just dead, untested code now.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
