This is the mail archive of the
mailing list for the glibc project.
Re: installing the <atomic.h> header?
On 11/4/2010 8:41 PM, Carlos O'Donell wrote:
> On Thu, Nov 4, 2010 at 8:11 PM, Petr Baudis <firstname.lastname@example.org> 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
>> 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
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
Chris Metcalf, Tilera Corp.