Comment 48 for bug 1805256

Revision history for this message
Philippe Mathieu-Daudé (philmd) wrote :

Isn't this fixed by commit 5710a3e09f9?

commit 5710a3e09f9b85801e5ce70797a4a511e5fc9e2c
Author: Paolo Bonzini <email address hidden>
Date: Tue Apr 7 10:07:46 2020 -0400

    async: use explicit memory barriers

    When using C11 atomics, non-seqcst reads and writes do not participate
    in the total order of seqcst operations. In util/async.c and util/aio-posix.c,
    in particular, the pattern that we use

              write ctx->notify_me write bh->scheduled
              read bh->scheduled read ctx->notify_me
              if !bh->scheduled, sleep if ctx->notify_me, notify

    needs to use seqcst operations for both the write and the read. In
    general this is something that we do not want, because there can be
    many sources that are polled in addition to bottom halves. The
    alternative is to place a seqcst memory barrier between the write
    and the read. This also comes with a disadvantage, in that the
    memory barrier is implicit on strongly-ordered architectures and
    it wastes a few dozen clock cycles.

    Fortunately, ctx->notify_me is never written concurrently by two
    threads, so we can assert that and relax the writes to ctx->notify_me.
    The resulting solution works and performs well on both aarch64 and x86.

    Note that the atomic_set/atomic_read combination is not an atomic
    read-modify-write, and therefore it is even weaker than C11 ATOMIC_RELAXED;
    on x86, ATOMIC_RELAXED compiles to a locked operation.