This is the mail archive of the
mailing list for the GCC project.
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
- From: "bert dot hubert at netherlabs dot nl" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Nov 2005 11:43:36 -0000
- Subject: [Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
- References: <email@example.com/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #13 from bert dot hubert at netherlabs dot nl 2005-11-08 11:43 -------
Subject: Re: __gnu_cxx::__exchange_and_add is called even for single threaded
On Tue, Nov 08, 2005 at 11:30:46AM -0000, pcarlini at suse dot de wrote:
> ------- Comment #12 from pcarlini at suse dot de 2005-11-08 11:30 -------
> In my opinion, the way to go is consistently using the macro __GTHREADS which
> is undefined when --enable-threads=single is passed. This is consistent with
> the approach already used in mt_allocator, for instance. And indeed, in
> nothing is thread-safe in that case (but much simpler and faster!).
__GTHREADS is fixed for libstdc++ depending on enable-threads=single|posix,
--whereas __gthread_active_p() depends on if the binary was compiled with
Indeed, other parts of libstdc++ already rely on __gthread_active_p().
Using __GTHREADS would get us halfway, but nobody in his right mind
(certainly no distributor) is going to compile with --enable-threads=single
on a platform that does posix - you get a crippled compiler. I'd hate to
have to keep two compilers around.
I've verified that adding a check on __gthread_active_p() to
bits/basic_string.h does the right thing. It only does so after a complete
recompile of libstdc++ though, the code is indeed instantiated earlier (as
you mentioned already).
The sticking point is people who don't do pthreads but DO need atomic
operations because they use some other threading system. There might be a
need for a mechanism to make __gthread_active_p() return true in that case.