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

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