Hi Stefan,
in the attempt to use Alex' ppoll-based timer rework for decoupled,
real-time capable timer device models I'm now scratching my head over
the aio_poll interface. I'm looking at dataplane/virtio-blk.c, just finding
static void *data_plane_thread(void *opaque)
{
VirtIOBlockDataPlane *s = opaque;
do {
aio_poll(s->ctx, true);
} while (!s->stopping || s->num_reqs > 0);
return NULL;
}
wondering where the locking is. Or doesn't this use need any at all? Are
all data structures that this thread accesses exclusively used by it, or
are they all accessed in a lock-less way?
Our iothread mainloop more or less open-codes aio_poll and is, thus,
able to drop its lock before falling asleep while still holding it
during event dispatching. Obviously, I need the same when processing
timer lists of an AioContext, protecting them against concurrent
modifications over VCPUs or other threads. So I'm thinking of adding a
block notification callback to aio_poll, to be called before/after
qemu_poll_ns so that any locks can be dropped / reacquired as needed. Or
am I missing some magic interface / pattern?
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
