This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 26 Jan 2012 20:39:40 +0000
- Subject: [Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
- Auto-submitted: auto-generated
- References: <bug-51798-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798
--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-26 20:39:40 UTC ---
Apologies for my phrasing. What I meant is that it's not a matter of
consistency.
Localising all uses of __sync_bool_compare_and_swap by adding an unnecessary
additional layer of indirection in atomicity.h would not have been appropriate.
GCC already abstracts the required CAS operation with
__sync_bool_compare_and_swap, so that is used directly when needed. One of the
main reasons for the wrappers in atomicity.h is to fall back to non-atomic ops
in non-threaded code, rather than just to localize the use of intrinisics.
Having a fall back for non-threaded code isn't necessary for the places where
__sync_bool_compare_and_swap is used in shared_ptr and parallel mode. Our
shared_ptr has a partial specialization for the non-threaded case, which
doesn't use CAS, and using parallel mode in non-threaded code doesn't make
sense. So __sync_bool_compare_and_swap is used directly. "It's own
atomicity.h" doesn't include a CAS operation, and I see no benefit to adding
CAS to that file.