> > Hmm, do we even need clock->using at this point? For example:
> >
> > qemu_clock_enable()
> > {
> > clock->enabled = enabled;
> > ...
> > if (!enabled) {
> > /* If another thread is within qemu_run_timers,
> > * wait for it to finish.
> > */
> > qemu_event_wait(&clock->callbacks_done_event);
> > }
> > }
> >
> > qemu_run_timers()
> > {
> > qemu_event_reset(&clock->callbacks_done_event);
> > if (!clock->enabled) {
> > goto out;
> > }
> > ...
> > out:
> > qemu_event_set(&eclock->callbacks_done_event);
> > }
> >
> > In the fast path this only does two atomic operations (an OR for reset,
> > and XCHG for set).
> >
> There is race condition, suppose the following scenario with A/B thread
> A: qemu_event_reset()
> B: qemu_event_reset()
> A: qemu_event_set() ----> B is still in flight when
> qemu_clock_enable() is notified
> B: qemu_event_set()
>
> I had tried to build something around futex(2) like qemu_event, but failed.
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).
Paolo
