On Tue, Jul 7, 2015 at 7:25 AM, Andres Freund <and...@anarazel.de> wrote: > 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?
I'm fine with that plan. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers