Потокобезопасный вектор

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

например, это может выглядеть так:

concurrent_vector<Object*>:
  size_t m_baseSize = 1000
  size_t m_size     = 3500
  part*  m_parts[6] = {
    part* part1, ----> Object*[1000]
    part* part2, ----> Object*[2000]
    part* part3, ----> Object*[4000]
    NULL,
    ...
  }

класс содержит фиксированный массив указателей на отдельные куски памяти с предметы, экспоненциально увеличивающиеся в размерах. Здесь предел 6 частей, поэтому 63000 деталей-но это можно изменить легко.

контейнер начинается с указателей всех деталей, установленных в NULL. Если элемент добавлен, создается 1-й кусок с размером m_baseSize, здесь 1000, и сохранено в m_parts[0]. Последующие пункты написаны там.

когда кусок заполнен, выделяется другой буфер, вдвое больше предыдущего (2000), и сохраняется в m_parts[1]. Это повторяется как требуемый.

все это можно сделать с помощью атомарных операций, но это конечно сложно. Это может быть проще, если все авторы могут быть защищены мьютексом, и только читатели полностью совпадают (например, если запись намного более редкая операция). Все потоки чтения всегда видят либо NULL в m_parts[i] или NULL в одном из буферов или допустимый указатель. Существующие элементы никогда не перемещаются в памяти, недействительны или что-то еще.

Что касается существующих библиотек, вы можете захотеть посмотреть Нить Строительные Блоки Intel, особенно его класс concurrent_vector содержатся. Сообщается, что он имеет следующие функции:

• произвольный доступ по индексу. Индекс первого элемента равен нулю.
• несколько потоков могут одновременно увеличивать контейнер и добавлять новые элементы.
• увеличение контейнера не делает недействительными существующие итераторы или индексы.

перечитывая вопрос, ситуация кажется немного другой.

std::vector плохо подходит для хранения объекты на который вы должны были бы сохранить ссылки, так как push_back может аннулировать все ссылки на сохраненные объекты. Но, вы храните кучу std::shared_ptr.

на std::shared_ptrs, хранящиеся внутри, должны обрабатывать изменение размера изящно (они перемещаются, но не объекты, на которые они указывают), пока в потоках вы не держите ссылки std::shared_ptrs хранится внутри вектора, но вы держите копии из них.

как использовать std::vector и std::deque вы должны синхронизировать доступ к структуре данных, так как push_back, хотя и не делает ссылку недействительной, изменяет внутренние структуры deque, и, таким образом, не разрешается работать одновременно с доступом deque.

OTOH,std::deque наверное, лучше всего подходит для повышения производительности; на каждый размер вы движетесь вокруг много std::shared_ptr, который, возможно, придется сделать заблокированный инкремент / декремент для пересчета в случае копирования / удаления (если они перемещены-как они должны - это должно быть отменено - но YMMV).

но самое главное, если вы используете std::shared_ptr просто, чтобы избежать потенциальных движений в векторе, вы можете полностью отказаться от него при использовании deque, поскольку ссылки не являются недействительными, поэтому вы можете хранить свои объекты непосредственно в deque вместо использования кучи распределение и косвенные / накладные расходы std::shared_ptr.