Re: __sync_lock_test_and_set on ARM

[Andrew Haley <aph-gcc at littlepinkcloud dot COM>]

David Daney writes:
 > Andrew Haley wrote:
 > > 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.
 > 
 > There is nothing that says that __sync_compar_and_swap() cannot expand 
 > to a libcall.

Err, if a port doen't have an implementation, that's what gcc does
anyway.  :-)

Andrew.