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] |
Hi Dhruv,Why not keep mt_alloc a proper multi_thread allocator ONLY. No ST support, and when __GTHREADS is not defined, use the default pool allocator without thread support.
I don't quite understand, but it's not simply a global lock on all operations. Much of the performance boost from mt allocator (in real world applications) comes from the fact that each bin is locked individually - if locking is needed at all.
Also, one more thing that comes to my mind is that is it possible to provide a Mt_Layer abstraction similar to debug_allocator? So, any allocator can be made simple mt compatible by doing:
Mt_Layer<Some_Allocator<Type>, Mutex_Type>?
That way, the Locking can be removed from the pool_allocator, and shifted to this layer, so that even if a user provides an ST allocator, and wants basic Mutex locking on allocation/deallocation, it can be done with one line of code?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |