From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nuyvx-00068j-0b for qemu-devel@nongnu.org; Thu, 25 Mar 2010 22:06:01 -0400 Received: from [140.186.70.92] (port=53306 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nuyvv-00061W-Du for qemu-devel@nongnu.org; Thu, 25 Mar 2010 22:06:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nuyrj-0008Kf-Uf for qemu-devel@nongnu.org; Thu, 25 Mar 2010 22:01:41 -0400 Received: from mail2.shareable.org ([80.68.89.115]:39378) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nuyrj-0008KZ-Og for qemu-devel@nongnu.org; Thu, 25 Mar 2010 22:01:39 -0400 Date: Fri, 26 Mar 2010 02:01:36 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 09/10] target-alpha: Implement load-locked/store-conditional properly. Message-ID: <20100326020136.GI19308@shareable.org> References: <20100325133920.GS16726@codesourcery.com> <4BAB853E.1070303@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BAB853E.1070303@twiddle.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: aurelien@aurel32.net, qemu-devel@nongnu.org, Nathan Froyd Richard Henderson wrote: > On 03/25/2010 06:39 AM, Nathan Froyd wrote: > > On Wed, Mar 24, 2010 at 05:11:43PM -0700, Richard Henderson wrote: > >> Use __sync_bool_compare_and_swap to yield correctly atomic results. > >> As yet, this assumes running on an strict-memory-ordering host (i.e. x86), > >> since we're still "implementing" the memory-barrier instructions as nops. > > > > Did the approach taken by other targets (arm/mips/ppc) not work on > > Alpha? > > Mips doesn't even pretend to be atomic. > > Powerpc and Arm -- if I've got this straight -- use some sort of stop-the-world > mutex+condition and then perform the compare-and-exchange by hand. I can't > see how that's better than using an actual compare-and-exchange provided by > the host cpu. In fact, I'm mildly horrified by the prospect. As I've just written with an example elsewhere on this thread, compare-and-exchange is insufficient to properly emulate ll/sc on some targets archs, when used with certain algorithms. I believe ARM is one such; I don't know about any of the others. But in nearly all cases, if not all the ones actually seen, it should be trivial to scan the guest instruction sequence between load-locked and store-conditional, and confirm that there's no funny business (non-register operations) in between that would prevent compare-exchange from emulating it correctly. So stop-the-world ought to remain in, but only as a last resort to be used when the ll/sc sequence doesn't pass the no-funny-business test. The example I gave might even be usable to test it. -- Jamie