From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QuRmm-0003iG-Jh for qemu-devel@nongnu.org; Fri, 19 Aug 2011 12:19:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QuRml-0005rS-3Q for qemu-devel@nongnu.org; Fri, 19 Aug 2011 12:19:08 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:45562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QuRmk-0005rO-TN for qemu-devel@nongnu.org; Fri, 19 Aug 2011 12:19:07 -0400 Received: by yih10 with SMTP id 10so2763277yih.4 for ; Fri, 19 Aug 2011 09:19:06 -0700 (PDT) Sender: Richard Henderson Message-ID: <4E4E8CF4.80605@twiddle.net> Date: Fri, 19 Aug 2011 09:19:00 -0700 From: Richard Henderson MIME-Version: 1.0 References: <20110818023558.GA66298@cs.nctu.edu.tw> <20110819025943.GA53608@cs.nctu.edu.tw> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Multi-threaded user program support? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, =?UTF-8?B?6Zmz6Z+L5Lu7?= On 08/18/2011 08:13 PM, Peter Maydell wrote: > On 19 August 2011 03:59, 陳韋任 wrote: >>> More generally and not x86-specific, there are problems with >>> the multithreaded user-mode support which I suspect exist because >>> nobody has ever sat down and worked out a coherent design for it, >>> including what might need to be thread-local and what locking >>> is required. So the result is that it mostly works but if you >> >> You mean some QEMU data structures need to be thread-local or lock >> protected in order to emulate guest multi-threaded program correctly? > > Approximately, yes (the third option being "redesign the data > structure so it can be sensibly protected"). See > https://bugs.launchpad.net/qemu/+bug/668799 for discussion of > one example. I suspect that to make things tractable for i386, which has so many LOCKable instructions, that we'll also have to implement at least a compare-and-swap primitive in TCG. r~