This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
- From: "pcarlini at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Nov 2005 12:06:01 -0000
- Subject: [Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
- References: <bug-24704-7094@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #16 from pcarlini at suse dot de 2005-11-08 12:06 -------
(In reply to comment #15)
> How about we make (or I contribute) a set of 'atomic-if-needed'
> 'exchange-and-add' and 'add' inlineable functions?
>
> These could just replace __gnu_cxx::__exchange_and_add in all places and
> automatically do the right thing: lock when needed and just add otherwise.
>
> The added bonus is that for unthreaded applications, still the majority,
> everything is inlined anyhow, which even works on i386.
Indeed, that's the idea. But:
1- Do you have a copyright assignment on file?
2- Are you aware of the various binary compatibility quirks? That means that
*nothing* has to to change (besides performance) wrt to exported symbols and
interoperability between binaries, if the user doesn't pass any --thread-model.
It's not trivial, but we can work out something for 4.2.
> My fear is that otherwise the unthreaded case is never ever going to see
> real use as the amount of people that will recompile their compiler or
> libstdc++ is going to be rather minimal.
To repeat: this is needed anyway, because we want to use consistently the
--thread-model configure option. Nothing will go in not checking also and
exploting the macro. Then comes everything else... And, sorry, *you* pointed
out this inconsistency in the first place ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704