Re: [PATCH v2 8/9] async: update documentation of the memory barriers

[Paolo Bonzini <pbonzini@redhat.com>]

On 3/7/23 16:54, Richard Henderson wrote:
>>
>> Just to be safe, I tried modeling this with cppmem 
>> (http://svr-pes20-cppmem.cl.cam.ac.uk/cppmem/); support for 
>> compare-and-swap is very limited, therefore the test looks nothing 
>> like the C code(*), but it should be ok:
> 
> You do realize that QSLIST_REMOVE_HEAD is not a compare-and-swap, right?
> 
> #define QSLIST_REMOVE_HEAD(head, field) do {                             \
>          typeof((head)->slh_first) elm = (head)->slh_first;               \
>          (head)->slh_first = elm->field.sle_next;                         \
>          elm->field.sle_next = NULL;                                      \
> } while (/*CONSTCOND*/0)

Yes, the compare-and-swap is just how I modeled the enqueuing thread's 
fetch_or

         cas_strong_explicit(&x, 0, 1, mo_acquire, mo_acquire);
         x.load(mo_relaxed).readsvalue(1); // fetch_or returned 0
         y.store(1, mo_release);           // bh inserted

while QSLIST_REMOVE_HEAD in the dequeuing thread is not ordered at all:

         y.store(0, mo_relaxed);           // QSLIST_REMOVE_HEAD
         x.store(0, mo_release);           // fetch_and

> As I read aio_bh_queue, this is exactly the situation you describe in 
> patch 1 justifying the introduction of the new barriers.

Only store-store reordering is required between QSLIST_REMOVE_HEAD and 
atomic_fetch_and(); and that one *is* blocked by atomic_fetch_and(), 
since mo_seq_cst is a superset of both mo_release.  The new barriers are 
needed for store-load reordering.

Paolo