Re: installing the <atomic.h> header?

[Chris Metcalf <cmetcalf at tilera dot com>]

On 11/4/2010 8:41 PM, Carlos O'Donell wrote:
> On Thu, Nov 4, 2010 at 8:11 PM, Petr Baudis <pasky@suse.cz> wrote:
>>  IMHO most of this stuff is not really a kernel service or worth a
>> library routine, but just making use of your instruction set properly.
>> So a compiler matter, solved not too badly with
>>
>>        http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Atomic-Builtins.html
>>
>>  I don't think the extra layer of <atomic.h> convenience routines is
>> all that significant; and no kernel calls are wrapped by this, AFAICS.
> On a purely techincal note, some architectures do provide wrappers for
> kernel helper routines. However, no userspace application should ever
> call them, they should use the the GCC atomic builtins as you suggest.
>
> Some architectures require kernel arbitration depending on the way in
> which the ISA matches or does not match the implemented atomic
> operation. As two examples: On HP PA-RISC the ISA only defines "load
> and clear word", and the kernel always arbitrates a compare and swap
> using a light-weight syscall mechanism. On ARM for anything older than
> ARMv6 you use a kernel helper to complete a compare and exchange
> operation (or memory barrier).

Thanks to folks for providing some insight here.

Yes, on TILEPro we also use light-weight syscalls for the atomic routines,
though on TILE-Gx we do not.  That's what I was referring to in the
original post as "too complicated for users".  We were directly wrapping
those syscall instructions in <atomic.h> and exposing that header to userspace.

In fact, we already had some partial implementation of the __sync_xxx
routines in gcc, so I've finished those for both of our platforms, and
removed the dependency on using <atomic.h> in those few places that had
them, and will convert the tile architecture <bits/atomic.h> to use the
builtins.

In fact, I wonder if the right thing to do here is to provide a
"sysdeps/gcc/" directory that provides "bits/atomic.h" using only the
__sync_xxx builtins, and allow architectures to imply it?  That could allow
some code to be factored out of the per-architecture headers.

That takes care of the glibc issues, but for the interested, there is a bit
more "color" to this issue.  There are enough "tricky" things that
low-level userspace code wants to do to make it worth continuing to provide
a header for those things.  So we'll continue to have an <arch/atomic.h>
header for applications to use if they wish.  This includes not only some
convenience macros (atomic_increment(), for example) but also some things
like "read without allocating a cache line" (atomic_read_nocache()) and
"write without waiting for the store buffer" (atomic_write_now()).  We also
have two barrier macros in there with comments explaining which ones are
helpful when (atomic_compiler_barrier(), expanding to the standard asm(""
::: "memory"), and and atomic_full_barrier(), expanding to
__sync_synchronize()).

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com