Il sab 17 mag 2025, 01:41 Akihiko Odaki <akihiko.od...@daynix.com> ha
scritto:
> I think we only need a store-release, which is ensured even by the C11
> read-modify-write operation; we only need to ensure that ev->value is
> set to EV_SET after all stores specified earlier appear.
>
You really need a barrier to order the store against the load
unfortunately. Likewise in qemu_event_wait(). It's really central to this
synchronization pattern, otherwise it's possible that neither side sees the
action of the other (set does not see the request to wake, or wait does not
see EV_SET).
Paolo
> >
> > if (qatomic_xchg(&ev->value, EV_SET) == EV_BUSY) {
> >
> >
> > Removing the qatomic_read() works, but it's more expensive in the case
> > that the event is already set.
>
> Removing the qatomic_read() (while keeping smp_mb()) is more expensive
> in that case indeed, but I'to m not so sure if the case is common enough
> that it depreciates the overhead added in the other cases.
>
> I don't know whether the qatomic_read() has improved the performance or
> not, but perhaps it is still a premature optimization.
>
> > > The barrier before qemu_futex_wake_all(ev) could be unnecessary
> because
> > there is probably one in FUTEX_WAKE. But not being able to audit Windows
> > makes me a bit uneasy about it.
>
> With "[PATCH v3 01/10] futex: Check value after qemu_futex_wait()",
> qemu_event_wait() always calls qatomic_load_acquire(&ev->value) or
> qatomic_cmpxchg(&ev->value, EV_FREE, EV_BUSY) before returning, so a
> store-release of ev->value is sufficient to ensure ordering and we don't
> need to rely on qemu_futex_wait() for that.
>
> Regards,
> Akihiko Odaki
>
>
