On 25/11/2015 15:04, David Engraf wrote: >>> >> >> No, you don't. Who is reading iothread_locked during >> qemu_cond_wait_iothread? No one, because it is a thread-local variable >> whose address is never taken. > > prepare_mmio_access is reading iothread_locked by using > qemu_mutex_iothread_locked after qemu_tcg_wait_io_event calls > qemu_cond_wait. All one the same thread.
Sure, but who has set iothread_locked to false during the execution of qemu_cond_wait? No one, because it's a thread-local variable. If it's true before qemu_cond_wait, it will be true after qemu_cond_wait and you don't need qemu_cond_wait_iothread... unless your compiler is broken and doesn't generate TLS properly. Can you compile cpus.c with -S and attach it? Paolo > qemu_tcg_cpu_thread_fn > -> qemu_tcg_wait_io_event > -> qemu_cond_wait acquires the mutex > > qemu_tcg_cpu_thread_fn > -> tcg_exec_all -> tcg_cpu_exec -> cpu_exec > -> cpu_exec ends up in calling prepare_mmio_access
