Robert Haas <robertmh...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
