On Fri, Aug 02, 2013 at 11:33:40AM +0800, liu ping fan wrote: > On Thu, Aug 1, 2013 at 9:28 PM, Alex Bligh <a...@alex.org.uk> wrote: > > Paolo, > > > > > > --On 1 August 2013 08:19:34 -0400 Paolo Bonzini <pbonz...@redhat.com> wrote: > > > >>> > True, qemu_event basically works only when a single thread resets it. > >>> > But there is no race condition here because qemu_run_timers cannot be > >>> > executed concurrently by multiple threads (like aio_poll in your > >>> > bottom half patches). > >>> > >>> ... or, if rebasing on top of my patches, qemu_run_timers *can* be > >>> executed concurrently by mulitple threads, but in respect of any given > >>> QEMUTimerList, it will only be executed by one thread. > >> > >> > >> ... so the event would be placed in QEMUTimerList, not QEMUClock. > > > > > > Correct > > > > > >> qemu_clock_enable then will have to visit all timer lists. That's > >> not hard to do, > > > > > > Correct, v4 of my patch does this. > > > > > >> but as locks proliferate we need to have a clear > >> policy (e.g. BQL -> clock -> timerlist). > > > > > > But doesn't do the locking bit yet (Pingfan is going to do that I hope) > > > Seem that Stefanha had been involved in this, and sent out his patches :)
Hi Ping Fan, I dropped the series where I added locks to qemu-timer.c from a few weeks ago. With your series rebased onto Alex's series, I think my patches are no longer needed? Stefan
