From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1bBq-00024Q-JE for qemu-devel@nongnu.org; Wed, 25 Nov 2015 09:36:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1bBm-0002yW-CR for qemu-devel@nongnu.org; Wed, 25 Nov 2015 09:36:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1bBm-0002yQ-74 for qemu-devel@nongnu.org; Wed, 25 Nov 2015 09:36:54 -0500 References: <565485A0.5090902@sysgo.com> <5654883F.9050509@redhat.com> <56557AA2.9080100@sysgo.com> <5655AA1F.8060906@sysgo.com> <5655B706.6060306@redhat.com> <5655BFEA.50407@sysgo.com> From: Paolo Bonzini Message-ID: <5655C781.8090201@redhat.com> Date: Wed, 25 Nov 2015 15:36:49 +0100 MIME-Version: 1.0 In-Reply-To: <5655BFEA.50407@sysgo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] qemu_mutex_iothread_locked not correctly synchronized List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Engraf , qemu-devel@nongnu.org Cc: Fam Zheng 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