This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]