This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/4] Add atomic operations similar to those provided by C11.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 30 Oct 2014 20:55:12 +0000
- Subject: Re: [PATCH 2/4] Add atomic operations similar to those provided by C11.
- Authentication-results: sourceware.org; auth=none
- References: <1414617613 dot 10085 dot 23 dot camel at triegel dot csb> <1414619416 dot 10085 dot 46 dot camel at triegel dot csb> <Pine dot LNX dot 4 dot 64 dot 1410292156440 dot 15119 at digraph dot polyomino dot org dot uk> <1414622734 dot 10085 dot 76 dot camel at triegel dot csb> <Pine dot LNX dot 4 dot 64 dot 1410292257040 dot 15119 at digraph dot polyomino dot org dot uk> <1414661232 dot 10085 dot 89 dot camel at triegel dot csb> <Pine dot LNX dot 4 dot 64 dot 1410301711530 dot 2316 at digraph dot polyomino dot org dot uk> <1414693238 dot 10085 dot 150 dot camel at triegel dot csb> <Pine dot LNX dot 4 dot 64 dot 1410302009301 dot 16421 at digraph dot polyomino dot org dot uk> <1414701510 dot 10085 dot 196 dot camel at triegel dot csb>
On Thu, 30 Oct 2014, Torvald Riegel wrote:
> > My guess is that on the system where a problem reordering was observed, it
> > was sufficient to stop the compiler from reordering the loads (but there
> > might be issues for some other system). And this sort of code, where
> > there aren't other atomic operations nearby, is a case where we'd need to
> > be particularly careful about checking the performance impact of inserting
> > barriers.
>
> But if there are issues for other archs, we need to insert a barrier
> anyway, agreed? If we want to write generic, non-arch-specific code,
Yes, subject to considering whether there's any more efficient approach
available.
> > Comparing code for one architecture, at the time of each conversion, seems
> > appropriate (with additional benchmarking for cases that don't otherwise
> > involve atomics).
>
> How do we handle bug fixes? When fixing a bug, do you want performance
> parity too?
No, but if the fix is in a critical path we should look more carefully at
what the most efficient way to acheive the fix is.
> By "involve atomics", do you mean specifically atomic read-modify-write
> ops, so atomic ops other than just loads and stores?
Yes.
--
Joseph S. Myers
joseph@codesourcery.com