This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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]

Re: About __gthread_active_p()


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

Ah, I didn't read closely enough.  I now see what you want.

It used to be possible to instantiate containers in the STL with
exactly the allocation policy that you want.  You could remove the
tentative mutex locking code entirely when you knew (e.g.) the access
pattern was inside another lock, etc.  That was done by passing false
as the second template argument to the default allocator.

Things have changed in that area and that feature appears to have been
removed during updating w.r.t. the standard allocator pattern.

Regards,
Loren


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