Il 05/07/2013 19:51, Jan Kiszka ha scritto: > On 2013-07-05 14:39, 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). > > What do you mean with this? We need main-loop independent timers for any > task that depends on timely alarm delivery. Do your patches keep this in > mind as well?
These are orthogonal issues. Stefan's usecase does not need timely delivery. >> 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. > > I suppose you know that vm_clock cannot be read outside BQL yet due to > timers_state and, under TCG, icount. Any ideas regarding this already? I > didn't have to solve that problem so far as I only need CLOCK_REALTIME > outside BQL. I was thinking of a seqlock. It should be quite cheap, since there would be hardly any contention. No ideas about host_clock's notifiers. Paolo