qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 09/10] target-alpha: Implement load-locked/store


From: Nathan Froyd
Subject: Re: [Qemu-devel] [PATCH 09/10] target-alpha: Implement load-locked/store-conditional properly.
Date: Thu, 25 Mar 2010 09:06:12 -0700
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Thu, Mar 25, 2010 at 08:46:06AM -0700, 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.

It pretends just as much as ppc and arm.  See translate.c:OP_ST_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.

Oh, I didn't say it was pretty.  But it does work fairly well in
practice--enough to pass most of glibc's NPTL testsuite, for instance.
(The remaining cases are tricky things, like cross-process locks.)  I
think--though Paul would remember better than I--that the stop-the-world
approach might have been taken due to a desire to continue compiling
with gcc < 4.1.  I don't know how much of a desdirata that still is.

(stop-the-world is also somewhat less complex than the previous
implementation, which involved page protection games.)

Certainly using actual compare-and-exchange would be much faster.

-Nathan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]