On 09/24/2014 07:57 PM, Andres Freund wrote:
> On 2014-09-24 12:44:09 -0400, Tom Lane wrote:
>> Andres Freund <andres@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