Re: RFC on mt_allocator.h

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

>  We could add a new producer-consumer test. Do you have one in mind?

First, I'd make a small change to allocator_thread.cc.  I'd flush the 
container with operator=(), because clear() doesn't necessarily 
deallocate.  I'd also consider adding support for maps, by using 
insert() instead of push_back() and inserting unique values.

Then, I'd create a test that uses two producer-consumer pairs, so the 
number of threads in the test is the same as in allocator_thread.cc.  
The producer inserts data into the test container, and the consumer 
removes this data.  Container access must be serialized by a lock, and 
all of these pieces are encapsulated by a single class.  The 
constructor has one argument, the iteration count, and it starts the 
producer thread.  The producer thread starts the consumer, produces the 
specified number of elements, and then joins with the consumer before 
exiting.  The consumer thread removes data from the container via 
swap() and operator=(), and it exits when it's removed the specified 
number of elements.  The destructor joins with the producer thread, so 
the test may be timed as follows:

	clear_counters(time, resource);
	start_counters(time, resource);
	{
		ProducerConsumerTest<Container> pct1(iterations);
		ProducerConsumerTest<Container> pct2(iterations);
	}
	stop_counters(time, resource);

This isn't ideal.  It would be better if the thread functions collected 
the statistics, so these wouldn't include the overhead of 
starting/stopping threads.  But that would require more effort, and I 
don't think that's necessary.

A more serious issue is the consumer spinning on an empty container.  
I'm not sure if this damage the results.  If necessary, I'd block the 
consumer and use a condition variable to unblock it.  The producer has 
to lock the container in order to insert an element, so it can reliably 
test its size, etc.


Felix