Параллельный доступ к большой коллекции предметов

Question

Я работаю над проектом симуляции, используя c ++ как для Windows, так и для Linux.

В симуляции будет несколько тысяч объектов (возможно, 3000-5000). Планируется иметь несколько потоков, выполняющих действия над объектами, чтобы можно было использовать многоядерные машины, например, один поток обрабатывает перемещение и расположение объектов, один (или более) обрабатывает взаимодействие между объектами, один обрабатывает создание новых объекты.

Однако для обеспечения правильной работы для этого потребуется синхронизация между потоками. Поэтому я подумал, что каждый объект должен содержать (pthread mutex / CRITICAL_SECTION) в зависимости от платформы, и тогда каждый поток может заблокировать объекты, над которыми он сейчас работает. Из-за большого количества объектов конфликт должен быть редким, поэтому он должен быть быстрым.

Итак, мой первый вопрос: слишком много мьютексов 3000-5000 pthread или критических секций Windows? Я не знаю, какие ограничения есть у обеих систем. Или есть лучший способ добиться этого?

Мой второй вопрос касается структур данных для хранения объектов. Поскольку объекты могут создаваться и «умирать», я считаю, что лучший способ - сохранить «список» активных объектов, через которые рабочие потоки могут проходить. C ++ список не является потокобезопасным, хотя. Если бы один из моих потоков удалил объект, мне нужно было бы синхронизировать его с другим объектом, выполнив «next ()» в списке. Кроме того, мне нужно убедиться, что «следующий» объект был заблокирован, прежде чем перемещать в него итератор, поэтому мне понадобится какая-то глобальная блокировка для всей коллекции, которую я должен получить до вставки / удаления объектов, но также и до переход к следующему объекту в потоке.

Это кажется довольно болезненным и потенциально медленным. Есть ли лучший способ?

Answer 1

Посмотрите на коллекции без блокировки.Я считаю, что Intel Threading Building Blocks (с открытым исходным кодом) имеет некоторые из них.

Answer 2

В частности, на вашей платформе Windows вы можете посмотреть Тонкие блокировки чтения / записи (SRW) - это позволит нескольким одновременным считывателям.

Answer 3

Вместо того, чтобы потоки выполняли разные действия с объектами, почему бы не каждому потоку работать с разными объектами?Похоже, вы делаете столкновения частиц.Я работал над проектом, похожим на этот, хотя мой не был нарезным.Но если вы можете сгруппировать свои объекты в «пространства», каждый поток может работать в своем собственном пространстве и передавать объекты из одного пространства в другое.Вы убьете свою производительность, если у вас есть 1 поток, выполняющий отслеживание положения, и 1 поток, выполняющий вычисления столкновений, потому что эти вычисления очень тесно связаны.Поток (как правило) хорош только тогда, когда один поток не зависит напрямую от других.

Answer 4

Нет никакого ограничения на число pthread_mutex_t с, которое вы можете создать в Linux - их не нужно нигде регистрировать централизованно. Разблокированный мьютекс не требует никаких ресурсов, кроме байтов, используемых для хранения pthread_mutex_t.

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