------- 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
