Re: About __gthread_active_p()

[Dhruv Matani <dhruvbird at gmx dot net>]

On Thu, 2004-04-22 at 22:11, Loren James Rittle wrote:
> > 	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.

Actually, it will be called, but not in the context for any container's
modification functions. Meaning, that there will not be any concurrent
insertions in the same or different containers. However, constant
members such as find for map which are thread safe will be called from
may threads concurrently. Now, for this operation, there is not need for
the allocator to be thread safe, because as it is, there are no
concurrent insertions happening for the same or different containers for
this particular test-suite. The program on which this test-file was
modeled also suffers from the same defect/shortcoming, etc... So, there
is an unnecessary overhead for the locking, etc... in the allocators.

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

I can't do that, because the rest of the program relies on linking with
-lpthread, because threads are being used. Again, the allocator need not
be thread safe because the containers are not being used that way.

The ideal thing to do would be to have a macro that let the user
override the deduced value from __gthread_active_p(). So, suppose the
user explicitly defines that macro, then the allocators would think that
they have to work according to what is defined.

So, something like:

#define USER_OVERRIDE 0 //No thread support
#define USER_OVERRIDE 1 //Enable thread support.

#if defined USER_OVERRIDE
  //Use the value of USER_OVERRIDE.
  #if USER_OVERRIDE == 0

  #else

  #endif
#else
  //Use the value of __gthread_active_p().
#endif


Would this be feasible to implement?


-- 
        -Dhruv Matani.
http://www.geocities.com/dhruvbird/

Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html