Re: [Qemu-devel] [PATCH 0/3] qemu-timer: make QEMUTimer functions thread-safe

[Stefan Hajnoczi <stefanha@redhat.com>]

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