This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: About __gthread_active_p()
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: dhruvbird at gmx dot net
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Thu, 22 Apr 2004 11:41:01 -0500 (CDT)
- Subject: Re: About __gthread_active_p()
- References: <1081879809.1325.6.camel@localhost.localdomain>
- Reply-to: rittle at labs dot mot dot com
> 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