ARM: enable interpreter, add locks code

[Boehm, Hans]

> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org 
> [mailto:java-patches-owner@gcc.gnu.org] On Behalf Of Daniel Jacobowitz
> Sent: Wednesday, July 11, 2007 2:48 PM
> To: David Daney
> Cc: Andrew Haley; java-patches@gcc.gnu.org; gcc-patches@gcc.gnu.org
> Subject: Re: ARM: enable interpreter, add locks code
> 
> On Wed, Jul 11, 2007 at 12:58:28PM -0700, David Daney wrote:
> > Andrew Haley wrote:
> > 
> > > +/* Atomic compare and exchange.  These sequences are not actually
> > > +   atomic; there is a race if *ADDR != OLD_VAL and we 
> are preempted
> > > +   between the two swaps.  However, they are very close 
> to atomic, and
> > > +   are the best that a pre-ARMv6 implementation can do without
> > > +   operating system support.  LinuxThreads has been using these
> > > +   sequences for many years.  */
> > 
> > Wow!  That is terrible.
> 
> Actually it works very well :-)
The problem of course is that this works perectly for some use cases,
e.g. when it's used to implement test-and-set for a spin-lock.  And it
probably almost never fails on a uniprocessor.  I'd expect it to do
fairly badly on a multicore processor for use cases for which the
atomicity really matters.

My impression is that there are some recent ARM processors that no
longer implement swp, at least not in hardware.  (It's been deprecated
since V6).  I'd expect it to do badly on those, too.

Thus it sounds to me like it really depends.  And the right test systems
may be hard to come by at the moment.

> 
> > Is there some way to do proper synchronization if the 
> target CPU supports it?
> 
> You would have to configure gcc specifically for an armv6 or 
> armv7 processor, or add relevant multilibs.  Or require a 
> sufficiently recent kernel, which has magic for this.  
> There's no ready way to check at runtime without a performance hit.

After startup overhead, it's presumably a load of a global followed by a
predictable branch, right?

I'm curious since my own libatomic_ops code has a similar problem ...

> 
> --
> Daniel Jacobowitz
> CodeSourcery
>