ALSchwalm
MSVC and static thread_local
Is it necessary for the Pools to be static? https://github.com/ALSchwalm/lfpAlloc/blob/master/lfpAlloc/PoolDispatcher.hpp#L35
MSVC do not support thread_local with types that have non trivial destructors/constructors. the other way we can implement TLS manually using TLS Keys API. however in this case on application exit if i define TLS ptr class as static smth goes wrong and multiple delete instructions got called
Syntactically, the pools must be static as thread_local is not allowed for data members without static storage class specification. Logically, the pools do not have to be static for the allocator to work (or be standards-compliant, by my reading of the standard). This is because it is possible for objects allocated in one thread to be deallocated in another, and so the implementation is able to handle deallocation of memory from 'foreign' allocators. It should make no difference if the original allocator is in another thread (as may be the case currently), or if the pools are not static and it is a different instance in the same thread (not currently possible, but would be if pools were not static).
MSVC and Windows is a hell in terms of c++11 features support. Can you please explain if https://github.com/ALSchwalm/lfpAlloc/blob/master/lfpAlloc/ChunkList.hpp#L60 should be thread safe by design? i'm asking because MSVC do not support thread safe static initialisers so it potentially should be rewritten with locks if it should be thread safe.
also regarding static thread_local in above question: we can define it as non static object but implement Pool class the same way as ChunkList is done through singleton. i wonder if this way we will emulate the initial idea?
on the other hand your PoolDispatcher is already static in Allocator...
ChunkList's constructor should be thread-safe.
I believe your proposal would be a viable workaround, however I should point out that this allocator was written for a specific use case, and may not have desirable performance characteristics when used generally. In many cases, using a malloc replacement like jemalloc may provide better allocation performance. That being said, I am happy to continue answering any questions you may have, and I would be interested to hear how lfpalloc performs in your application if you decide to use it.
the current implementation is a good reference how ever it will not compile with Apple Clang for example and wont with MSVC... but if you try to fix it for all that platforms it will become a mess of #ifdef :)
I have another question: i dont see how u delete allocated Chunks... i see that in Pool destructor u call ChunkList::dealocate but only on head chunk... what happens to all other created Chunks?
I'm not sure what's going on with the clang version apple is shipping. It builds and runs fine on 3.6 on arch linux, and I think it worked back to 3.4 or so, possibly earlier. It also builds on current GCC.
The pool destructor actually invokes deallocateChain. These chains are singly linked lists of 'cells' which are allocated from chunks. So destructing a pool is just returning the chain the pool allocates from to the corresponding chunk list.
well it irritates as much as it possible :) but unfortunately thats life developing multi-platform solutions. u have to compile using native toolchains so customers can integrate it easily in their stuff...
yep i see the idea of linked list and chains. but when ChunkList finally got destroyed it never free its chain... deallocateChain method just add cell into list. while allocateChain actually create new ChunkNodes which is never freed