[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Using aio_poll for timer carrier threads
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] Using aio_poll for timer carrier threads |
Date: |
Mon, 19 Aug 2013 15:21:14 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 |
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).
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.
Paolo
- Re: [Qemu-devel] Using aio_poll for timer carrier threads, (continued)
Re: [Qemu-devel] Using aio_poll for timer carrier threads, Paolo Bonzini, 2013/08/13