qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/8] qemu-thread-win32: cleanup, fix, document QemuEvent


From: Paolo Bonzini
Subject: Re: [PATCH 3/8] qemu-thread-win32: cleanup, fix, document QemuEvent
Date: Mon, 6 Mar 2023 15:20:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

On 3/6/23 14:31, David Hildenbrand wrote:

-    smp_mb_acquire();
-    if (value == EV_SET) {
-        /* If there was a concurrent reset (or even reset+wait),
-         * do nothing.  Otherwise change EV_SET->EV_FREE.
-         */
-        qatomic_or(&ev->value, EV_FREE);
-    }
+

[had the same thought on patch #2]

IIUC, the "read first" is an optimization to not unconditionally dirty the cache-line. But I assume we don't particularly care about that optimization on the reset path.

Thinking more about it, the intended usage of QemuEvent is either

    qemu_event_reset();
    if (!check()) {
         qemu_event_wait());
    }

or

    if (!check()) {
        qemu_event_reset();
        if (!check()) {
             qemu_event_wait());
        }
    }

If we don't care on the reset path we care much less on the wait path. Should I remove it and go straight to the cmpxchg, just for peace of mind?

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]