qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 2/3] qemu-timer: make qemu_timer_mod_ns() and


From: Alex Bligh
Subject: Re: [Qemu-devel] [PATCH v4 2/3] qemu-timer: make qemu_timer_mod_ns() and qemu_timer_del() thread-safe
Date: Mon, 30 Sep 2013 14:34:42 +0100

Mike,

> void qemu_clock_notify(QEMUClockType type)
...
> int64_t qemu_clock_deadline_ns_all(QEMUClockType type)
...
> I think these functions are always called now with the BQL held, so I
> wonder if they are good candidates for RCU?

These routines iterate through the list of timerlists held by
a clock.

They do not iterate through the list of active timers in a timer
list. I believe the latter is what active_timers_lock protects.

The list of timers attached to a clock is only modified when timers
are created and deleted which is (currently) under the BQL.




Sorry, and thanks for the correction re: active_timers_lock. I should
have said that clock->timerlists may need its own mutex if and when we
remove the BQL from the timer code.

Correct. The list of timerlists is only modified when a
QEMUTimerListGroup is created or destroyed (currently when an
AioContext is created or destroyed), and that is done with the
BQL held.

As you point out, it's currently walked by a couple of functions
that also have the BQL held.

I think the most likely change here is that the walkers might
move outside the BQL. Given modification of this list is so rare,
the lock would be very very read heavy, so RCU is probably a
sensible option.

This link may (or may not) help in understanding:
 http://blog.alex.org.uk/2013/08/24/changes-to-qemus-timer-system/

--
Alex Bligh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]