This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Transition to C11 atomics and memory model
- From: Chris Metcalf <cmetcalf at tilera dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Mon, 15 Sep 2014 19:37:38 -0400
- Subject: Re: Transition to C11 atomics and memory model
- Authentication-results: sourceware.org; auth=none
- References: <1410719669 dot 4967 dot 160 dot camel at triegel dot csb> <54170CCC dot 6030706 at redhat dot com>
On 9/15/2014 11:59 AM, Carlos O'Donell wrote:
* How do we deal with archs such as older SPARC that don't have CAS and
>other archs without HW support for atomics? Using modified algorithms
>should be the best-performing option (eg, if we can use one critical
>section instead of a complicated alternative that uses lots of atomic
>operations). However, that means we'll have to maintain more algorithms
>(even if they might be simpler).
No. Stop. One algorithm. All arches that can't meet the HW support for
atomics must enter the kernel and do the work there. This is just like hppa
and ARM do. They use a light-weight syscall mechanism and serialize in the
kernel.
Agreed! And, tilepro is also on that list of platforms with weak atomics that uses a light-weight syscall to serialize in the kernel. (Unlike tilegx, which has fairly rich atomics.)
On 9/15/2014 12:51 PM, Joseph S. Myers wrote:
* In some cases those macros are defined by GCC even though the operations
are out of line in libgcc. On PA the HAVE_sync_compare_and_swap* macros
are defined in pa-linux.h to cause __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* to
be predefined; for Tile GCC has special target-specific code to define
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_*. Do we believe such out-of-line libgcc
versions will work in glibc, and is it preferable to use them or inline
asm?
Yes, the tile out-of-line versions should work fine in glibc. The tilepro out-of-line atomics do the lightweight syscalls. On tilegx out-of-line support is only used for 1- and 2-byte atomics, which are not supported in hardware, so the out-of-line code does a 4-byte compare-and-exchange loop to synthesize the operation. However, I suspect we are also not using those sizes in glibc itself - or if we are, we might decide we don't want to be.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com