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
