tbb::memory_pool был основан на тех же местах, что и у tbb::scalable_allocator. Итак, как только пул памяти захватывает память изначально (в вашем случае, как вы указали, от tbb::scalable_allocator), он будет использовать те же механизмы для распространения и повторного использования в потоках. То есть он масштабируется и позволяет избежать глобального блокирования как можно больше. Хотя, поскольку память по-прежнему является общим ресурсом, в любом случае некоторая синхронизация потоков неизбежна. В частности, я ожидал бы большего разногласия в отношении начальных запросов на память, поскольку кэши для каждой нити не нагреты; а также scalable_allocator пытается сохранить баланс между масштабируемостью и потреблением памяти, поэтому он не сходит с ума, когда кэширование на потоках перераспределяет память между потоками, что также является видом синхронизации потоков (хотя и более масштабируемым, чем блокировка).
Что касается [очень] начального распределения памяти с помощью масштабируемого_allocator, он проходит через mmap или VirtualAlloc для достаточно больших объемов памяти, а не через malloc.
Есть ли какая-то конкретная куча? Темы, как правило, имеют собственное пространство стека, но разделяют кучу с процессом, который их создал. – Praetorian
Я тоже не понимаю, поскольку документ четко не обозначен, но из того, что я знаю, scalable_allocator не выделяет память непосредственно из динамической кучи, поэтому он не блокируется системным вызовом melloc() –
Я не должен скажем, динамическая куча, нет такой вещи. я имел в виду «кучу доли», которую использует системный вызов malloc(). –