Re: [Qemu-devel] [PATCH v2 2/2] qemu-timer: make qemu_timer_mod_ns() and qemu_timer_del() thread-safe

[Paolo Bonzini <pbonzini@redhat.com>]

Il 27/08/2013 10:55, Alex Bligh ha scritto:
>> + * Note that this function should not be used when other threads also access
>> + * the timer list.  The return value may be outdated by the time it is acted
>> + * upon.
>> + *
> 
> I'm in two minds as to whether there is a problem with the comment or the
> code here. Despite git's best endeavours, this is a comment on qemu_clock_has_timers,
> which is called in qemu_clock_warp in cpus.c. I'm still a little confused as
> to what thread(s) that can be called from.

This really means that calling this function must be done with care
because there is potential of races.  As long as you use aio_notify
properly so that qemu_clock_warp is called after every timer_mod, it
should be fine.
>> > @@ -531,6 +545,9 @@ void timer_mod_ns(QEMUTimer *ts, int64_t expire_time);
>> >  *
>> >  * Modify a timer to expiry at @expire_time, taking into
>> >  * account the scale associated with the timer.
>> > + *
>> > + * This function is thread-safe but the timer and its timer list must not be
>> > + * freed while this function is running.
>> >  */
>> > void timer_mod(QEMUTimer *ts, int64_t expire_timer);
> timer_mod and timer_mod_ns are inevitably called having just read the
> clock with qemu_clock_get. I am presuming these are thread safe (I haven't
> checked) and if so the documentation for them should be similar adjusted.
> Otherwise making these thread safe is all but useless.

rt_clock is thread safe.  host_clock is thread safe but there's the
question of where to run the notifiers.  Ping Fan has made vm_clock
thread safe for the non-icount case, probably I'll look at icount sometime.

Paolo