This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: __sync_lock_test_and_set on ARM
- From: Andrew Haley <aph-gcc at littlepinkcloud dot COM>
- To: "Phil Endecott" <spam_from_gcc_help_2 at chezphil dot org>
- Cc: "David Daney" <ddaney at avtrex dot com>, <gcc-help at gcc dot gnu dot org>
- Date: Thu, 13 Sep 2007 16:36:43 +0100
- Subject: Re: __sync_lock_test_and_set on ARM
- References: <46E95589.6060700@avtrex.com> <1189697368819@dmwebmail.japan.chezphil.org>
Phil Endecott writes:
> David Daney wrote:
> > Andrew Haley wrote:
> >> Phil Endecott writes:
> >> > Andrew Haley wrote:
> >> > > this stuff really should be done by the compiler.
> >> >
> >> > Yes. I've filed a bug asking for a __sync_lock_test_and_set builtin:
> >> >
> >> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33413
> >>
> >> Surer, but the problem is that for most of the things we want to do
> >> (lightweight locks, for example) __sync_lock_test_and_set() doesn't
> >> really do what we need: we need compare_and_swap(). That's why the
> >> kernel helper is so useful, because it's robust even if we are on
> >> pre-ARMv6 hardware.
> >
> > Probably the enhancement request should be expanded to include *all* the
> > __sync_* atomic memory primitives which includes compare_and_swap.
>
> No, because none of the others can be implemented without kernel
> support or other magic.
Yeah, I think that's right. Even in the case of post-v6 -- where it
actually is possible to do this safely in userland -- if it's
necessary to execute a bunch of instructions you might as well call a
subroutine.
Andrew.