Horton

Re: Broken atomics code on PPC with FreeBSD 10.3

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Date: 2017-01-02T21:04:17Z
Lists: pgsql-hackers 
I wrote:
> But that doesn't really detract from my point, which is that it's
> totally silly for us to imagine that char and word-wide atomic ops are
> interchangeable on all platforms and we can flip a coin to decide which
> to use as long as the configure probes don't fail outright.  Even given
> working code for the byte case, we ought to prefer int atomics on PPC.
> On other platforms, maybe the preference goes the other way.  I'd be
> inclined to follow the hard-won knowledge embedded in s_lock.h about
> which to prefer.

After further study, I'm inclined to just propose that we flip the default
width of pg_atomic_flag in generic-gcc.h: use int not char if both are
available.  The only modern platform where that's the wrong thing is x86,
and that case is irrelevant here because we'll be using arch-x86.h not
generic-gcc.h.

A survey of s_lock.h shows that we prefer char-width slock_t only on
these architectures:

x86
sparc (but not sparcv9, there we use int)
m68k
vax

So basically, the existing coding is optimizing for obsolete hardware,
and not even very much of that.

			regards, tom lane

Commits

  1. Prefer int-wide pg_atomic_flag over char-wide when using gcc intrinsics.

  2. Allow Pin/UnpinBuffer to operate in a lockfree manner.

  3. Avoid the use of a separate spinlock to protect a LWLock's wait queue.

  4. Move buffer I/O and content LWLocks out of the main tranche.

  5. Improve spinlock performance for HP-UX, ia64, non-gcc.