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 * strict ordering of accesses to volatile data. In particular, while the * xchg instruction implicitly acts as a memory barrier with 'acquire' * semantics, we do not have an explicit memory fence instruction in the * S_UNLOCK macro. We use a regular assignment 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 in the gcc manual. In Intel's compiler, * the -m[no-]serialize-volatile option controls that, and testing shows that * it is enabled 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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
