From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMG47-0005iI-9L for qemu-devel@nongnu.org; Fri, 04 Nov 2011 05:28:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMG46-0004PY-9K for qemu-devel@nongnu.org; Fri, 04 Nov 2011 05:27:59 -0400 Received: from mel.act-europe.fr ([194.98.77.210]:56744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMG45-0004P0-AL for qemu-devel@nongnu.org; Fri, 04 Nov 2011 05:27:58 -0400 Message-ID: <4EB3B006.6080504@adacore.com> Date: Fri, 04 Nov 2011 10:27:34 +0100 From: Fabien Chouteau MIME-Version: 1.0 References: <4EB1640F.2090604@adacore.com> <4EB1796B.7050901@adacore.com> <4EB181C4.1090501@redhat.com> <4EB19F6B.8020907@redhat.com> <4EB264D5.6070009@adacore.com> <4EB2689F.3060205@redhat.com> <4EB26CF4.7080806@redhat.com> <4EB27FF6.2040907@redhat.com> In-Reply-To: <4EB27FF6.2040907@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Multiple instances of Qemu on Windows multicore List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , Avi Kivity , qemu-devel@nongnu.org On 03/11/2011 12:50, Paolo Bonzini wrote: > On 11/03/2011 11:29 AM, Avi Kivity wrote: >> > It would ensure that two mutators wouldn't run concurrently. In some >> > sense, signal-safe code could then be considered thread-safe too. >> >> How so? The scheduler can switch between the two threads on every >> instruction. > > In general signal-safe is more stringent than thread-safe, but with two exceptions: memory barriers and locked memory access. On x86 (implied by Windows...) you might also assume that the compiler will generate arithmetic operations with a memory destination, which makes code like > > void cpu_interrupt(CPUState *env, int mask) > { > env->interrupt_request |= mask; /* <--- this */ > cpu_unlink_tb(env); > } > > signal-safe in practice---and even "thread-safe" on non-SMP systems. It's a huge assumption though, and I don't think it should be assumed anymore. What can we do to improve that? > > With iothread the architecture of the QEMU main loop is anyway completely different. > Are you saying that things are better or worst with iothread? -- Fabien Chouteau