About __gthread_active_p()

[Loren James Rittle]

> 	Ok, I have here a problem. Consider the test-suite file map_mt_find.cc
> in the performance folder. Now, this needs to be compiled with -lpthread
> for correct linking. This would mean that the mutex protection in all
> the allocators that use __gthread_active_p() will get activated at
> run-time. However, if you observe, then the insertion code for the
> map/multimap is a single-threaded one. Only the find operation is
> multi-threaded, because you can not concurrently insert into a
> map/multimap, since they are not thread-safe. So, this unnecessarily
> causes an overhead at run-time. How can this be avoided? Is there any
> way of signaling that even if the .exe file / binary contains
> pthread_create(), then the allocators are supposed to work as if it is a
> single threaded app., because not the containers/allocators but other
> code will need to work concurrently.

Dhruv,

In case no one answered: Once pthread_create() is present in the final
linked image, the idiom used by the gthr layer should activate mutex
protection where tentatively marked.  Poeple would be free to improve
the implementation of __gthread_active_p() however, I don't know of
any way to see if pthread_create() is present but will never be called.

Why don't you just build it twice, once linked against -pthread and
once without.  Other performance test cases do that.

Loren