Re: anole: assorted stability problems

Robert Haas <robertmhaas@gmail.com> writes:
> What we did do that touched s_lock.h was attempt to ensure that
> SpinLockAcquire() and SpinLockRelease() function as compiler barriers,
> so that it should no longer be necessary to litter the code with
> "volatile" in every function that uses those.  It is possible that
> this could be broken on HP-UX.  If _Asm_sched_fence() doesn't
> constraint the compiler appropriately, that could explain the problems
> we're seeing here.  But we're not the only one using that incantation,
> so I'm left scratching my head.

AFAICS, on non-gcc IA64, 9.4's version of S_UNLOCK defaulted to

#define S_UNLOCK(lock)        (*((volatile slock_t *) (lock)) = 0)

whereas in HEAD, we've got

#define S_UNLOCK(lock)    \do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)

which immediately raises the question of why omitting the "volatile"
cast is okay.  The comments for the gcc/icc version make it clear that
the volatile qual is pretty critical for those compilers.  I also wonder
if we don't need a second _Asm_sched_fence() after the lock release.
        regards, tom lane