Subj : Re: speed-up critical regions To : comp.programming.threads From : David Schwartz Date : Thu Jun 16 2005 03:13 pm wrote in message news:1118953608.965205.92830@g44g2000cwa.googlegroups.com... > The Hoard solution, as described by Emery Berger in his paper, is based > on local heaps per thread. But as I thought, the first operation he's > doing in the alloc/free functions is to lock the 'choosen' heap. So, > local heaps don't mean mutex free. You still have the overhead of a > lock operation in every allocation. So what? Is this handwaving or do you have some genuine reason to think this is an issue? > For David, what do you mean by: > >> "If thread A allocates an object, get it from thread A's allocator. If >> it's later freed by thread B, that's fine, just return the object to >> thread B's allocator". > The object is created inside a pool owned by the allocator of thread A. > How can you transfer it inside a pool owned by the allocator of thread > B? Or what do you understand by 'just return the object to thread B's > allocator'? I remind you that objects are inside pools which are > contiguous memory areas. Why does it matter? When the block is returned to the allocator, you check to see if there is another block contiguous with that block either at the beginning or end. If so, you coalesce. If not, you don't. When you rebalance, you can check if other allocators have a block that you can coalesce with that block, but in the fast path free, why bother? I get the impression you're trying to solve problems you don't actually have. That's great if you're trying to create the world's best per-thread allocator ever as a research project or something. But if that was the case, why all the basic questions? DS .