RFC on mt_allocator.h
Felix Yen
fwy@alumni.brown.edu
Wed Jan 14 20:43:00 GMT 2004
Stefan writes:
> You're more than welcome to help out on the development of
mt_allocator
> may it be documentation, testcases and/or features!
Benjamin suggested that I look at the tests, so I'm familiar with them.
If this allocator's single-threaded performance is adequate when
measured by the allocator.cc test, I'd advocate using it as the
underlying implementation of the default allocator. (I know I should
just run the test myself, but I also should have written this message a
few hours ago.) Doing this would not only improve multithreaded
performance, but reduce the maintenance burden and documentation
requirement. Somewhat paradoxically, the default allocator needn't be
described in great detail. It merely has to work reasonably well in
most cases. In this scenario, the pool allocator probably must remain,
but if it's deprecated there would be no need to improve its
documentation.
The other test (allocator_thread.cc) does a good job of exercising
multithreaded heap access, but each of its container elements is
accessed exclusively by a single thread. That's not very realistic,
but I can't quite make the case for adding a producer-consumer test,
even though it would have been my first choice.
Felix
More information about the Libstdc++
mailing list