простая потоковая реализация и быстрая реализация пула памяти?

Потокобезопасная проблема требует блокировки. Если вы хотите ослабить это, вам нужно ограничение, что только один поток когда-либо использует пул. Вы можете расширить это до двух потоков, если будете использовать круговой список свободных ресурсов, который я опишу ниже, с условием, что один поток отвечает за выделение, а другой — за освобождение.

Что касается использования вектора без какого-либо другого управления, это плохая идея... Как только вы начинаете фрагментироваться, ваши распределения получают удар.

Хороший способ реализовать это — просто выделить большой блок T. Затем создать циклическую очередь, достаточно большую, чтобы она указывала на каждый из этих блоков. Это ваш «бесплатный список». Вы можете просто использовать индексы. Если вы ограничиваете каждый пул до 65536 элементов, вы можете выбрать неподписанный шорт, чтобы сэкономить место (на самом деле это 65535, чтобы обеспечить эффективное управление циклической очередью)

Используя циклическую очередь, вы разрешаете выделение и освобождение с постоянным временем независимо от фрагментации. Вы также знаете, когда ваш пул заполнен (т. е. список свободных ресурсов пуст), и вы можете создать другой пул. Очевидно, что при создании пула необходимо заполнить свободный список.

Итак, ваш класс будет выглядеть примерно так:

template<class T, size_t initSize>
class MemPool
{
    vector<T> poolBuffer;              // The memory pool
    vector<unsigned short> freeList;   // Ring-buffer (indices of free items)
    unsigned short nHead, nTail;       // Ring-buffer management
    int nCount;                        // Number of elements in ring-buffer
    MemPool<T,initSize> *nextPool;     // For expanding memory pool

    // etc...
};

Теперь о блокировке. Если у вас есть доступ к инструкциям атомарного увеличения и уменьшения и вы достаточно осторожны, вы можете поддерживать свободный список с потокобезопасностью. Единственная требуемая блокировка в стиле мьютекса — это когда вам нужно выделить новый пул памяти.

Я изменил свое первоначальное мышление. Вам как бы нужны две атомарные операции, и вам нужно зарезервированное значение индекса (0xffff), чтобы вращаться для неатомарных операций в очереди:

// I'll have the functions atomic_incr() and atomic_decr().  The assumption here
// is that they do the operation and return the value as it was prior to the
// increment/decrement.  I'll also assume they work correctly for both int and
// unsigned short types.
unsigned short atomic_incr( unsigned short & );
int atomic_incr( int & );
int atomic_decr( int & );

Таким образом, распределение происходит примерно так:

T* alloc()
{
    // Check the queue size.  If it's zero (or less) we need to pass on
    // to the next pool and/or allocate a new one.
    if( nCount <= 0 ) {
        return alloc_extend();
    }

    int count = atomic_decr(nCount);
    if( count <= 0 ) {
        T *mem = alloc_extend();
        atomic_incr(nCount);     // undo
        return mem;
    }

    // We are guaranteed that there is at least 1 element in the list for us.
    // This will overflow naturally to achieve modulo by 65536.  You can only
    // deal with queue sizes that are a power of 2.  If you want 32768 values,
    // for example, you must do this: head &= 0x7fff;
    unsigned short head = atomic_incr(nHead);

    // Spin until the element is valid (use a reference)
    unsigned short & idx = freeList[head];
    while( idx == 0xffff );

    // Grab the pool item, and blitz the index from the queue
    T * mem = &poolBuffer[idx];
    idx = 0xffff;

    return mem;
};

В приведенном выше примере используется новая частная функция-член:

T * alloc_extend()
{
    if( nextPool == NULL ) {
        acquire_mutex_here();
        if( nextPool == NULL ) nextPool = new MemPool<T>;
        release_mutex_here();
        if( nextPool == NULL ) return NULL;
    }
    return nextPool->alloc();
}

Когда вы хотите освободиться:

void free(T* mem)
{
    // Find the right pool to free from.
    if( mem < &poolBuffer.front() || mem > &poolBuffer.back() )
    {
        if( nextPool ) nextPool->free(mem);
        return;
    }

    // You might want to maintain a bitset that indicates whether the memory has
    // actually been allocated so you don't corrupt your pool here, but I won't
    // do that in this example...

    // Work out the index.  Hope my pointer arithmetic is correct here.
    unsigned short idx = (unsigned short)(mem - &poolBuffer.front());

    // Push index back onto the queue.  As with alloc(), you might want to
    // use a mask on the tail to achieve modulo.
    int tail = atomic_incr(nTail);
    freeList[tail] = idx;

    // Don't need to check the list size.  We assume everything is sane. =)
    atomic_incr(nCount);
}

Обратите внимание, что я использовал значение 0xffff, фактически как NULL. Установка, очистка и вращение этого значения предназначены для предотвращения ситуации гонки. Вы не можете гарантировать, что безопасно оставлять старые данные в очереди, когда несколько потоков могут вызывать free, в то время как у вас есть другие потоки, вызывающие alloc. Ваша очередь будет проходить циклически, но данные в ней могут быть еще не установлены.

Вместо индексов, конечно, можно было бы просто использовать указатели. Но это 4 байта (или 8 байтов в 64-разрядном приложении), и накладные расходы памяти могут не стоить того, в зависимости от размера данных, которые вы объединяете. Лично я бы использовал указатели, но почему-то в этом ответе мне показалось проще использовать индексы.