Re: compiler barriers (was: New statistics for WAL buffer dirty writes)

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(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +