Re: [Qemu-devel] Using aio_poll for timer carrier threads

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2013-08-13 16:45, Paolo Bonzini wrote:
> Il 13/08/2013 09:56, Jan Kiszka ha scritto:
>> 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?
> 
> There is some locking in aio_bh_poll.  It is pretty lightweight because
> adding elements and deleting them is done under a lock, while the list
> is walked without taking it (because deletion is only done by the thread
> that walks).  We could do something similar for file descriptors; timers
> are more complicated because insertions happen for every mod_timer.
> 
> Using an AioContext lock for timers is somewhat complicated for lock
> ordering, because context A could try to modify a timer from context B,
> at the same time when context B is modifying a timer from context A.
> This would cause a deadlock.

That's like MMIO access on device A triggers MMIO access on B and vice
versa - why should we need this, so why should we support this? I think
the typical case is that timers (and their lists) and data structures
they access have a fairly close relation, thus can reuse the same lock.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux