Re: compiler barriers (was: New statistics for WAL buffer dirty writes) - Mailing list pgsql-hackers

Was there any conclusion from these ideas?

---------------------------------------------------------------------------

On Wed, Aug  1, 2012 at 11:35:56AM -0400, Robert Haas wrote:
> On Wed, Aug 1, 2012 at 10:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I think you may be right that using __asm__ __volatile__ in gcc
> > S_UNLOCK cases would be a big step forward, but it needs more research
> > to see if that's the only fix needed.
> 
> Looking through the spinlock implementations in s_lock.h, we start
> with a bunch of GCC-ish things:
> 
> - i386 uses __asm__ __volatile__
> - x86_65 uses __asm__ __volatile__
> - ia64 uses __asm__ __volatile__ on GCC, and _InterlockedExchange on
> the Intel compiler
> - arm uses GCC integer atomics if available, and __asm__ __volatile__ otherwise
> - s390 uses __asm__ __volatile__
> - sparc uses __asm__ __volatile__
> - ppc uses __asm__ __volatile__
> - m68k uses __asm__ __volatile__
> - vax uses __asm__ __volatile__
> - ns32k uses __asm__ __volatile__
> - alpha uses __asm__ __volatile__
> - mips uses __asm__ __volatile__
> - m32r calls what appears to be a system-provided tas() function
> - SuperH uses __asm__ __volatile__
> 
> Presumably all the ones that are using __asm__ __volatile__ for TAS()
> could also use that for a compiler barrier at release time, so the
> interesting cases are ia64, arm, and m32r.  The ARM case is not a
> problem, because the GCC builtins are defined as compiler barriers.
> For the Intel compiler case on ia64, I believe the existing definition
> of pg_compiler_barrier() in storage/barrier.h should suffice for a
> release barrier.  I have no idea what to do about m32r.
> 
> The remaining implementations are for non-GCC compilers, which is
> where things obviously get harder:
> 
> - Univel CC (is that sco cc?) uses an idiosyncratic asm inline syntax
> - Tru64/alpha uses a system-provided primitive called __LOCK_LONG_RETRY
> - hppa uses __asm__ __volatile__ on GCC; otherwise, it uses hpux_hppa.s
> - itanium uses _Asm_xchg
> - sgi uses OS or compiler primitives called test_and_set and test_then_and
> - sinix uses OS or compiler primitives called acquire_lock and release_lock
> - aix uses OS or compiler primitives called _check_lock and _clear_lock
> - sparc uses pg_atomic_cas, which is implemented in sunstudio_x86.s or
> sunstudio_sparc.s
> - win32 uses InterlockedCompareExchange()
> 
> Of these, Itanium and Win32 are not too hard to handle because there's
> are already compiler barrier definitions in storage/barrier.h:
> _Asm_sched_fence() for Itanium and _ReadWriteBarrier() for Win32.  The
> rest are anybody's guess.  I suspect that SGI, SINIX, and AIX are
> *probably* fine as they are, because if the primitives they are using
> are provided by the platform, then the compiler ought to be smart
> enough to know what they mean.  Even if they're just functions in a
> system library somewhere, we're already relying on the fact that a
> call to a globally accessible function acts as a compiler barrier, so
> I doubt we are any worse off if we rely on it here, too.  However, the
> remaining cases - Univel CC, Tru64/alpha, hppa non-GCC, and sparc -
> probably need work.
> 
> -- 
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +