Re: Atomics hardware support table & supported architectures - Mailing list pgsql-hackers

On Mon, Jun 23, 2014 at 12:29 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> > That we have support for platforms that we haven't even documented as
>> > working (e.g. SuperH) or platforms that don't work in the realword
>> > (m32r) means that that one has to think about and research so many more
>> > edge cases that it's really hard to make progress. I don't know how
>> > often I've now sequentially gone through s_lock.h, s_lock.c,
>> > src/backend/port/tas to understand all the supported combinations.
>>
>> I agree that s_lock.h is the most painful part of this whole thing,
>> mostly because I'd really like to get to the point where
>> SpinLockAcquire() and SpinLockRelease() function as compiler barriers.
>
> s_lock.h is basically gone in my patch btw. Only old comments + defines
> for TAS/TAS_SPIN/S_UNLOCK etc mapping the old calls onto atomic flags
> remain.
> The new code should, hopefully, all be barrier safe.

Urp.  I'm not sure that's at all a good idea.  I don't love s_lock.h,
but if we make a wholesale change, we risk breaking things that work
today in obscure ways that are hard to find and debug.  I thought we
were talking about adding new facilities with their own fallbacks, not
massively reengineering the facilities we've already got.

> I'll omit !gcc PA-RISC unless somebody complains. I don't think I'll be
> able to modify hpux_hppa.s + build infrastructure correctly and there's
> no buildfarm. That means it'll require --disable-spinlocks.

I dunno whether we should care in that particular case, but in general
I don't think it's OK for lack of support for the *new* atomics to
prevent us from using the *existing* TAS support.

>> Again, the concern that was expressed at the developer's meeting was
>> that the performance characteristics of the CAS loop might be
>> significantly different from a native atomic op as to cause us
>> heartburn.  I think that's a valid concern... but if everything in
>> common use has both CAS and fetch-and-add, then I think there's
>> probably no issue here.
>
> Well, there's platforms where both CAS and atomic add are implemented
> using load linked/store conditional. So neither really is 100%
> native. But that's essentially how CAS et al are implemented in
> microcode on pretty much all somewhat recent cpus anyway.

I think on platforms that expose LL/SC, we have to assume that
spurious failures will be infrequent enough not to matter to
performance.  If they do, that's something that's going to have to be
fixed by the hardware manufacturer, not us.  There is a danger here
that we could end up with optimizations that are wins on some
platforms and losses on others, but I think we're going to have to
live with that.  Refusing to use atomic ops at all isn't a viable way
forward.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company