Neil Conway <neilc@samurai.com> writes:
> Another way to fix the problem would be to have S_LOCK() and S_UNLOCK()
> force $CC to not rearrange loads and stores by themselves, without
> relying upon volatile pointers.
That would certainly be better if possible, but AFAIK it's not.
(Perhaps there is a gcc-specific hack, but certainly not one that's
portable to all compilers. "volatile" is the only tool the C standard
gives us.)
Note that the S_LOCK and S_UNLOCK macros *do* incorporate commands to
prevent hardware-level reorderings, on platforms where this is
necessary. The problem at hand is basically that those optimization-
fence instructions are not visible to the compiler...
> From talking with Andrew @ Supernews on IRC, he suggested the asm
> "volatile" keyword as a possible solution ("volatile" is used for some
> platform's S_LOCK/S_UNLOCK, but not the default S_UNLOCK(), which is
> used by x86 and x86_64). [1] suggests that this keyword prevents
> rearrangement of code around the inline ASM, but the GCC docs ([2])
> don't actually state this:
Interesting point. The bug case at hand involved rearrangement of code
around an S_UNLOCK, which on x86 doesn't use any asm block, only a store
through a volatile pointer. Maybe if it had used such a block we'd not
have seen the bug. Still, I think we have to do the volatile pointers
in order to guarantee correct results on non-gcc compilers, so it's not
clear that there's any point in pursuing the question of whether gcc by
itself could offer a nicer solution.
regards, tom lane