Re: anole: assorted stability problems

On 2015-06-29 22:45:49 -0400, Robert Haas wrote:
> On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
> >> On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> > On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
> >> >> #define S_UNLOCK(lock) \
> >> >> do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
> >> >
> >> > Robert, how did you choose that? Isn't _Asm_sched_fence just a compiler
> >> > barrier? Shouldn't this be a _Asm_mf()?
> >>
> >> The point of the commit was to make spinlocks act as compiler barriers
> >> as well as CPU barriers. So I was just looking to add a compiler
> >> barrier to what was already there.
> >
> > You removed a volatile at the same time, and volatile on IA64 has
> > acquire/release semantics.
>
> Can you explain what you mean by volatile having acquire/release
> semantics? I don't see how volatile can create a CPU barrier, but I'm
> guessing that it somehow can and that you're about to enlighten me.

It's a IA64 pecularity. I think it started with intel's compiler, but
since then at least msvc and gcc copied it. In essence volatile reads
implicitly have acquire semantics, and volatile writes release. That's
relatively cheap on IA64 because they have 'opcode tags' marking normal
moves etc. as having release or acquire semantics (mov.rel etc.).

We even have a comment about it that scratches the surface a bit:
/*
* 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.
*/