How to make the Memory Pool thread safe ? [modified][solved]
-
-
I hear that the memory pool can improve the performance. It means that allocate a block of memory and then new the class object in this memory block, but how to make the thread safe and proceeding safe?
modified on Wednesday, September 22, 2010 11:10 AM
A memory pool (implemented as a custom allocator or overiding new/delete for a class) can improve speed a lot. HOWEVER before you do make sure that your app is actually eating up loads of execution time in the ordinary allocator before doing anything about it. I've seen plenty of people mess about and spend ages optimising allocators and get nothing concrete out of it. If you decide to use a custom allocator then you make it thread safe the way you do any other object - use a synchronisation object and lock it when doing any operations on the object. Incidentally I've seen the cost of synchronisation wipe out any benefit a custom allocator gives you, so again make sure you're just not replacing a runtime library bottleneck with a carefully crafted homemade one. There are ways you can reduce locking bottlenecks from an allocator but you start needing to use multiple arenas to allocate from and switch between them on each allocation. This can then start messing up locality of reference (unless you manage interleaved arenas) and again slow everything down again. Anyway, the point I'm really making here is measure how long your app spends in the allocator. If it's taking an appreciable length of time consider using a third party custom allocator or implementation of new and delete and only write your own if it's still not fast enough. Another idea would be to use a garbage collector - if you google "Hans" "Boehm" and "garbage collection" you can find a decent one (if you like that sort of thing) that's written by one of the luminaries of the C++ standards committee. Garbage collection has the advantage that when you delete objects the memory is not immediately freed and is recovered in one fell swoop later by the garbage collector reducing contention for the allocator when releasing objects. Cheers, Ash
modified on Monday, September 20, 2010 7:05 AM
-
A memory pool (implemented as a custom allocator or overiding new/delete for a class) can improve speed a lot. HOWEVER before you do make sure that your app is actually eating up loads of execution time in the ordinary allocator before doing anything about it. I've seen plenty of people mess about and spend ages optimising allocators and get nothing concrete out of it. If you decide to use a custom allocator then you make it thread safe the way you do any other object - use a synchronisation object and lock it when doing any operations on the object. Incidentally I've seen the cost of synchronisation wipe out any benefit a custom allocator gives you, so again make sure you're just not replacing a runtime library bottleneck with a carefully crafted homemade one. There are ways you can reduce locking bottlenecks from an allocator but you start needing to use multiple arenas to allocate from and switch between them on each allocation. This can then start messing up locality of reference (unless you manage interleaved arenas) and again slow everything down again. Anyway, the point I'm really making here is measure how long your app spends in the allocator. If it's taking an appreciable length of time consider using a third party custom allocator or implementation of new and delete and only write your own if it's still not fast enough. Another idea would be to use a garbage collector - if you google "Hans" "Boehm" and "garbage collection" you can find a decent one (if you like that sort of thing) that's written by one of the luminaries of the C++ standards committee. Garbage collection has the advantage that when you delete objects the memory is not immediately freed and is recovered in one fell swoop later by the garbage collector reducing contention for the allocator when releasing objects. Cheers, Ash
modified on Monday, September 20, 2010 7:05 AM
good answer. I've bumped (5-ved) the question also.
Watched code never compiles.
-
good answer. I've bumped (5-ved) the question also.
Watched code never compiles.
-
I hear that the memory pool can improve the performance. It means that allocate a block of memory and then new the class object in this memory block, but how to make the thread safe and proceeding safe?
modified on Wednesday, September 22, 2010 11:10 AM
Override the new/delete operators and use "placement new" syntax to alloc in a predetermined location, managed by you.
onwards and upwards...
-
I hear that the memory pool can improve the performance. It means that allocate a block of memory and then new the class object in this memory block, but how to make the thread safe and proceeding safe?
modified on Wednesday, September 22, 2010 11:10 AM
If you take the memory from your own Win32 Heap, then it is already thread-safe. See HeapCreate.