This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Future atomic operation cleanup
- From: Torvald Riegel <triegel at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Fri, 05 Sep 2014 19:51:22 +0200
- Subject: Re: Future atomic operation cleanup
- Authentication-results: sourceware.org; auth=none
- References: <53F74A93 dot 30508 at linux dot vnet dot ibm dot com> <53F74CE4 dot 5070809 at twiddle dot net> <53FF3551 dot 8020503 at linux dot vnet dot ibm dot com> <1409240266 dot 6045 dot 62 dot camel at triegel dot csb> <53FF5889 dot 5080006 at linux dot vnet dot ibm dot com> <1409306115 dot 6045 dot 71 dot camel at triegel dot csb> <54005FAA dot 9000802 at linux dot vnet dot ibm dot com> <1409318874 dot 6045 dot 73 dot camel at triegel dot csb> <540080DF dot 6030205 at linux dot vnet dot ibm dot com> <20140829215226 dot F2A392C3A30 at topped-with-meat dot com>
On Fri, 2014-08-29 at 14:52 -0700, Roland McGrath wrote:
> I don't see a problem with conditional code based on available compiler
> version--that is, conditional code within the atomic.h implementations
> themselves. What I take to be the main thrust of Torvald's suggestion is
> that we get ASAP to a situation where all the code outside of actual
> atomic.h implementations themselves is using a new atomic.h API that has
> semantics and signatures identical to, and names similar to, the
> C11-supporting builtins.
Yes. We might pick names that are similar to the C11 functions too, and
that might even be easier to learn for people.
> That enables us to clean up, fix, and optimize
> all the actual uses of atomics throughout the codebase, without waiting
> until we can rely on requiring newer compiler versions throughout.
Yes. It would also separate the use of a certain weak atomic op (e.g.,
memory_order_relaxed) from whether a particular architecture actually
implements it efficiently, and how.