On Tue, Feb 25, 2014 at 10:33:49AM -0700, Eric Blake wrote: > On 02/25/2014 10:19 AM, Stefan Hajnoczi wrote: > > Keep the thread ID around so we can report it via QMP. > > > > There's only one problem: qemu_get_thread_id() (gettid() wrapper on > > Linux) must be called from the thread itself. There is no way to get > > the thread ID outside the thread. > > > > This patch uses a condvar to wait for iothread_run() to populate the > > thread_id inside the thread. > > > > > + > > + /* Wait for initialization to complete */ > > + qemu_mutex_lock(&iothread->init_done_lock); > > + qemu_cond_wait(&iothread->init_done_cond, > > + &iothread->init_done_lock); > > + qemu_mutex_unlock(&iothread->init_done_lock); > > Generally, cond_wait needs to be done in a loop, where you also check > the condition (in this case, that thread_id was actually set) - a > pthread implementation is allowed to do spurious wakeups even if no > other thread has managed to change the condition that you were waiting for.
You are right, POSIX is explicit about this: "When using condition variables there is always a Boolean predicate involving shared variables associated with each condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return." I figured no other thread issues pthread_cond_signal/broadcast so spurious wakeups cannot occur but I was wrong. Stefan
