Paolo Bonzini <pbonz...@redhat.com> wrote: > On 09/09/2015 12:41, Juan Quintela wrote: >>> > + qemu_mutex_unlock_iothread(); >>> > + atomic_set(&cpu->throttle_thread_scheduled, 0); >>> > + g_usleep(sleeptime_ns / 1000); /* Convert ns to us for usleep call */ >>> > + qemu_mutex_lock_iothread(); >> >> Why is this thread safe? >> >> qemu_mutex_lock_iothread() is protecting (at least) cpu_work_first on >> each cpu. How can we be sure that _nothing_ will change that while we >> are waiting? > > You only have to be sure that the queued work list remains consistent; > not that nothing changes.
But nothing else is protected by the iothread? That is the part that I can't see. > (BTW, there is a queued patch that moves the queued work list to its own > mutex, and indeed it releases that mutex while calling the work function). >> A fast look through the tree don't show anything that >> runs here that drops the lock. > > Actually, the existing implementation of throttling does. :) See, that happens when you search in a modified tree O:-) Thanks for the fast answer. Later, Juan.
