[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: aio_wait_bh_oneshot() thread-safety question
From: |
Paolo Bonzini |
Subject: |
Re: aio_wait_bh_oneshot() thread-safety question |
Date: |
Tue, 24 May 2022 19:21:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
On 5/24/22 14:40, Kevin Wolf wrote:
Why is the barrier in aio_bh_enqueue() not enough? Is the comment there
wrong?
aio_notify() has another barrier. This is a little bit too late, but if
I misunderstood the aio_bh_enqueue() one, it could explain why it was
never observed.
The missing one that I (and I think Vladimir) were talking about is at the
end of the execution of the bottom half, not at the beginning:
/* Context: BH in IOThread */
static void aio_wait_bh(void *opaque)
{
AioWaitBHData *data = opaque;
data->cb(data->opaque);
data->done = true;
aio_wait_kick();
}
void aio_wait_kick(void)
{
/* The barrier (or an atomic op) is in the caller. */
if (qatomic_read(&global_aio_wait.num_waiters)) {
aio_bh_schedule_oneshot(qemu_get_aio_context(), dummy_bh_cb, NULL);
}
}
where there is no barrier in the caller to separate reading data->done
(qatomic_set would be nice, if only for clarity) from reading num_waiters.
Paolo