[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications

["bert dot hubert at netherlabs dot nl" <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
applications

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
> mt_alloc
> 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
--pthread.

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.

Ideas?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704