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++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications



------- Comment #18 from pcarlini at suse dot de  2005-11-08 14:34 -------
(In reply to comment #17)
> > 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 ;)
> 
> True - but would  #if __GTHREADS if(__gthread_active_p()) be ok? So check
> both?

Sure, this is the general idea. I'm a little bit concerned that for something
apparently so elemental as an addiction (atomic, yes...) we are going to add
a conditional, but probably, given the many cycles of atomics, it's ok. Any
chance you can benchmark a bit that? I gather you already played with adding
those checks, can you measure the overhead of the conditional alone compared
to not doing nothing (i.e., non-atomic inline addition/subtraction).

> I've discussed a bit with Momchil Velikov and we feel it might be good if
> there were a generic way for an application or library to signal that
> multiple threads might be active. Momchil fakes this by defining the pthread
> symbol that __gthread_active_p() looks for, but that is not generic enough.

Frankly, this is another issue. What we are going to do for *this* PR is
working along the lines of mt_allocator and the rest of the library, which
are largely relying on __gthread_active_p() in its present form and __GTHREAD,
nothing else. If you feel something can be improved about __gthread_active_p()
please submit a detailed, separate PR. Probably, it's not even a libstdc++
PR...


-- 


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


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