On Fri, Jul 05, 2013 at 02:39:43PM +0200, Stefan Hajnoczi wrote: > This series makes the following functions thread-safe: > > qemu_mod_timer_ns() > qemu_mod_timer() > qemu_del_timer() > qemu_timer_pending() > > The following were already thread-safe: > > qemu_free_timer() > qemu_new_timer() > qemu_timer_expired() > > Now it is possible to use QEMUTimer outside the QEMU global mutex. Timer > callbacks are still invoked from the main loop. If a thread wishes to run > timer callbacks it must use a thread-safe QEMUBH (which Ping Fan Liu is > working > on). > > Note that host_clock is not thread-safe because it keeps state and invokes > reset notifiers. Device emulation threads mostly care about vm_clock, so this > is not a problem. > > Stefan Hajnoczi (3): > qemu-timer: drop outdated signal safety comments > qemu-timer: add QEMUClock->active_timers list lock > qemu-timer: add qemu_alarm_timer->timer_modified_lock > > qemu-timer.c | 129 > +++++++++++++++++++++++++++++++++++++++++------------------ > 1 file changed, 90 insertions(+), 39 deletions(-)
I'm rethinking this patch series. If we go ahead and give every AioContext a QEMUClock which also fires during aio_poll(), then thread-safety is no longer an issue because: 1. Event loops like the dataplane thread will use the AioContext QEMUClock since are based purely on aio_poll(). 2. The AioContext timers are implemented using g_poll()/ppoll() timeout in the same thread instead of global mechanisms (like signals). It's not necessary to access timers from multiple threads. Leaving this series for now unless someone needs thread-safe QEMUTimer, in which case I can finish it off. Stefan
