From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1CyE9Q-0000pJ-8M
	for qemu-devel@nongnu.org; Mon, 07 Feb 2005 14:02:24 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1CyE9O-0000nE-Gc
	for qemu-devel@nongnu.org; Mon, 07 Feb 2005 14:02:22 -0500
Received: from [129.104.30.34] (helo=mx1.polytechnique.org)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1CyDtP-0005bY-Iy
	for qemu-devel@nongnu.org; Mon, 07 Feb 2005 13:45:51 -0500
Received: from [84.99.204.237] (237.204.99-84.rev.gaoland.net [84.99.204.237])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ssl.polytechnique.org (Postfix) with ESMTP id 57E9133324
	for <qemu-devel@nongnu.org>; Mon,  7 Feb 2005 19:45:50 +0100 (CET)
Message-ID: <4207B799.6020707@bellard.org>
Date: Mon, 07 Feb 2005 19:46:49 +0100
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] testandset asm fix
References: <200502061443.38384.paul@codesourcery.com>	<42077171.6030308@bellard.org>
	<20050207173448.GA26461@xi.wantstofly.org>
In-Reply-To: <20050207173448.GA26461@xi.wantstofly.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Lennert Buytenhek wrote:
> On Mon, Feb 07, 2005 at 02:47:29PM +0100, Fabrice Bellard wrote:
> 
> 
>>OK. Anyway, the locking in QEMU is mostly boggus. If SMP is
>>implemented someday with host threads, then it will be the right
>>time to correct it !
> 
> 
> Differences in strict/loose memory ordering between different
> processor types will be a bigger problem for SMP emulation, IMHO.
> What are your plans on that?

For x86 on x86 it won't be a problem if we use the same locking 
instructions. For the rest, using high level locks might suffice at the 
expense of efficiency. In the worst case we can simply not use threads 
and do explicit scheduling based on a cycle counter.

Fabrice.