On 2015-06-30 11:35:56 +0200, Andres Freund wrote:
> On 2015-06-29 22:58:05 -0400, Tom Lane wrote:
> > So personally, I would be inclined to put back the volatile qualifier,
> > independently of any fooling around with _Asm_double_magic_xyzzy
> > calls.
>
> I'm not sure. I think the reliance on an explicit memory barrier is a
> lot more robust and easy to understand than some barely documented odd
> behaviour around volatile. On the other hand the old way worked for a
> long while.
>
> I'm inclined to just do both on platforms as odd as IA6. But it'd like
> to let anole run with the current set a bit longer - if it doesn't work
> we have more problems than just S_UNLOCK(). It seems EDB has increased
> the run rate for now, so it shouldn't take too long:
> http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=HEAD
So, it's starting to look good. Not exactly allowing for a lot of
confidence yet, but still:
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=HEAD
I'm inclined to simply revise the comments now, and *not* reintroduce
the volatile. The assumptions documented in:
/** Intel Itanium, gcc or Intel's compiler.** Itanium has weak memory ordering, but we rely on the compiler to enforce*
strictordering of accesses to volatile data. In particular, while the* xchg instruction implicitly acts as a memory
barrierwith 'acquire'* semantics, we do not have an explicit memory fence instruction in the* S_UNLOCK macro. We use a
regularassignment to clear the spinlock, and* trust that the compiler marks the generated store instruction with the*
".rel"opcode.** Testing shows that assumption to hold on gcc, although I could not find* any explicit statement on that
inthe gcc manual. In Intel's compiler,* the -m[no-]serialize-volatile option controls that, and testing shows that* it
isenabled by default.*/
don't sound exactly bullet proof to me. I also personally find explicit
barriers easier to understand in the light of all the other spinlock
implementations.
Comments?