A caution on dynamic allocation with multithreading

[sje]

A caution on dynamic allocation with multithreading

If your program uses dynamic storage allocation in a multithreading environment, either with direct calls or with calls hidden in a template class instantiation, then you have to be prepared for speed performance degradation due to thread blocking.

In C and C++, there is only one storage heap per process, and every thread in that process shares the same heap. This means that all access to the heap requires a mutex control. When one thread locks the mutex, until that thread exits the storage management call, all other threads which need to access the heap get blocked.

Symbolic avoids most of this kind of blockage by using its own per-thread storage management with per-class recycling routines. This is not particularly complicated, but it does require some forethought with its implementation.

[flok]

That problem can be resolved, at least on linux, using tcmalloc (https://code.google.com/p/gperftools/).

[sje]

Some third party schemes have problems with per-thread heaps when an object allocated in one thread gets used by a second thread. If the object remains in use after the first thread exits, it will vanish or it will be a source of a memory leak.

Symbolic avoids this by not having hidden per-thread heaps. The program uses objects with destructors which do the right thing regardless if the destructing thread is or is not the constructing thread.

I say that private allocators with recycling by class in the way to go, for both single threaded and multithreaded. C++ with templates makes this easy. However, you can't always be sure that a third party template will work efficiently. And it won't if it doesn't recycle and has to hit the heap over and over.