The FFMA allocators owned by the threads don't normally get de-allocated unless a thread is terminated which isn't something that happens in cachegrand unless the service is entirely terminated.
In the tests though that's a different story, FFMA is continuously allocated and de-allocated as part of the testing framework and,under some extreme contention, it might happen that at the end of the multi-threaded tests more than 1 thread will try to de-allocate the same FFMA allocator owned by another thread that was able to terminate succesfully.
In this case a race condition might be triggered which this PR patches as follow:
queue_mpmc is now embedded in ffma_t instead of being a pointer
ffma_t is allocated via mmap
ffma_t is never de-allocated to guarantee that if there is thread sending back memory to free during the shutdown it's there
Of course this will lead the memory loss of a page but we don't really need to care, cachegrand terminates the worker threads only during the shutdown and therefore the memory loss would happen only during that phase.
The FFMA allocators owned by the threads don't normally get de-allocated unless a thread is terminated which isn't something that happens in cachegrand unless the service is entirely terminated.
In the tests though that's a different story, FFMA is continuously allocated and de-allocated as part of the testing framework and,under some extreme contention, it might happen that at the end of the multi-threaded tests more than 1 thread will try to de-allocate the same FFMA allocator owned by another thread that was able to terminate succesfully.
In this case a race condition might be triggered which this PR patches as follow:
Of course this will lead the memory loss of a page but we don't really need to care, cachegrand terminates the worker threads only during the shutdown and therefore the memory loss would happen only during that phase.