Re: RFC on mt_allocator.h

[Felix Yen <fwy at alumni dot brown dot edu>]

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