On Aug 01 2013, Alex Bligh wrote: > >So actually there is another problem with this patch (both the > >condvar and the event approach are equally buggy). If a timer > >on clock X disables clock X, qemu_clock_enable will deadlock. > > Yes. I believe there will be a similar problem if a timer > created or deleted an AioContext (clearly less likely!) > > >I suppose it's easier to ask each user of qemu_clock_enable to > >provide its own synchronization, and drop this patch. The simplest > >kind of synchronization is to delay some work to a bottom half in > >the clock's AioContext. If you do that, you know that the timers > >are not running. > > I'm not sure that's true. If two AioContexts run in different > threads, would their BH's and timers not also run in those two > different threads?
Suppose a thread wants to do qemu_clock_enable(foo, false), and the code after qemu_clock_enable assumes that no timers are running. Then you should move that code to a bottom half in foo's AioContext. Paolo
