From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1Lkr-0005JI-L0 for qemu-devel@nongnu.org; Wed, 28 May 2008 09:31:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1Lko-0005FY-7T for qemu-devel@nongnu.org; Wed, 28 May 2008 09:31:48 -0400 Received: from [199.232.76.173] (port=45296 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1Lkn-0005F4-Te for qemu-devel@nongnu.org; Wed, 28 May 2008 09:31:45 -0400 Received: from mail.codesourcery.com ([65.74.133.4]:37862) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1Lkn-0003kw-Qb for qemu-devel@nongnu.org; Wed, 28 May 2008 09:31:46 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Threading Qemu Date: Wed, 28 May 2008 14:31:38 +0100 References: <20080527233155.d05f3f7a3b090fc6839dcb689abb911d.486e192adc.wbe@email.secureserver.net> <483D0C78.8020406@qumranet.com> <20080528122850.GC19738@shareable.org> In-Reply-To: <20080528122850.GC19738@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset="ansi_x3.4-1968" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805281431.39574.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > > plus you will need to take care for memory barriers, and many more things > > (it looks very complex) > > Don't forget _implied_ memory write barrier after every write op on > x86 target. With x86 target on hosts where writes are not > processor-ordered like x86, you need to put a write-write barrier after > every write - except when you can prove it's not needed. But that's > really hard. Yup. I had a proof of concept implementation that used the TLB to enforce per-page exclusive access. This worked, but the locking overhead to achieve this was fairly horrible, particularly when you have pages that bounce between CPUs frequently (e.g. kernel locks). The nice thing about this is that you don't need to do anything special to ensure atomicity, it just works. > Both atomiciy and ordering don't have to be solved if instead you use > "software scheduled" threads on any architecture - e.g. see GNU Pth. > Then you won't get real parallelism on a multiprocessor host, but you > can simulate any multiprocessor target correctly. That's what qemu currently does. Paul