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

On 2014-06-23 12:08:08 -0400, Robert Haas wrote:
> > That we still have !PG_USE_INLINE support although all buildfarm animals
> > support it since 4c8aa8b (fixing acc) causes absurd constructs
> > (STATIC_IF_INLINE) and fugly macro usage making it harder to read
> > and modify code. I spend a good chunk of time just to make that work. Even if
> > nobody's going to ever use it.
> 
> I expect that we're eventually going to make a decision to require
> inline support, but that commit was only last month, so probably not
> just yet.

We were in pretty much the same position before - it was just the quiet
inline test tripping us up...

> > 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.

> > I agree that we shouldn't actively try to break stuff. But having to
> > understand & blindly modify unused code is on the other hand of actively
> > breaking platforms. It's actively hindering development.
> 
> It's actively hindering a small number of important patches, but most
> developers, most of the time, do not need to care.

True. I guess I just seem to find myself hit by this a bit heavily :)

> > While I indeed have that fallback code, that's statement is still not
> > entirely true. We still need to add atomics support for lots of
> > platforms, otherwise they're just going to be 'less supported' than
> > now. Are we fine with that and just'll accept patches?
> 
> I guess it depends on which platforms are affected.  I certainly don't
> think any new facilities we add need to be more comprehensive than
> what I did in barrier.h, and in fact I think we could omit a few of
> the things I have there, like PA-RISC, Itanium, and Alpha.  And, yeah,
> if somebody needs an atomics implementation for a platform we haven't
> got yet, they can submit a patch.

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've now also removed sunstudio*.s because sunstudio has provided
intrinsics for a *long* while. No idea whether it'll work out of the
box, but it shouldn't be hard to mop up eventual bugs.

> >> The question that
> >> needs to be resolved in order to move forward here is this: Consider
> >> the set of platforms we support, ignoring any that don't have
> >> spinlocks.  Do any of them have only one of fetch-and-add, or do they
> >> all have both or neither?  If it's the latter, then we're talking
> >> about moving from a two-tiered system that looks like this:
> >
> > Since fetch-and-add is trivially implemented using CAS, there's not much
> > need to distinguish between CAS and CAS + fetch_and_add. From my POV the
> > restriction to just CAS/fetch_and_add isn't actually buying much. Pretty
> > much all platforms but older gcc ones have atomic intrinsics since
> > forever. Once you've dug up the documentation for one operation not
> > adding two more or so doesn't save much.
> 
> 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.

Greetings,

Andres Freund

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