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

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

On 2013-08-19 15:21, Paolo Bonzini wrote:
> Il 13/08/2013 16:54, Jan Kiszka ha scritto:
>>>> 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.
> 
> Yes, that's true.  Still it would have to be documented, and using
> too-coarse locks risks having many BQLs, which multiplies the complexity
> (fine-grained locking at least keeps critical sections small and limits
> the amount of nested locking).

As this lock does not require taking other locks while holding it, it
should actually be fine.

> 
> I like Stefan's patches to make the timer list thread-safe, especially
> if we can optimize it (with RCU?) to make the read side lockless.

What is a pure read-side in that context? Checks if some timer is
expired? Given that RCU write sides are heavier than plain mutexes and
many typical accesses (mod, del, expire) involve writing, such an
optimization may also be counterproductive.

Jan

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