Общие ресурсы для чтения по потокам - PullRequest
0 голосов
/ 18 сентября 2018

Это вопрос производительности чтения в многопоточном коде.

Итак, вот ситуация.У меня есть большой объем данных, которые необходимо знать нескольким тысячам лиц, чтобы отреагировать.Эти данные изменяют каждый кадр, поэтому давайте назовем его frame data.

У каждого из этих объектов есть функция, которую необходимо запустить, каждый кадр позволяет вызвать ее run().Функция run () требует частого чтения (но никогда не записи) в frame data.Предположим также, что frame data находится в куче и, следовательно, не клонируется при создании новых потоков.

Все эти объекты могут быть run() последовательно в одном потоке или если платформа, выполняющая этот код, будет полезна длясущности могут быть объединены в несколько потоков pthreads или каждый run() в своем собственном pthread.

Таким образом, по существу каждый кадр frame data обновляется, тогда каждый объект получает run() в произвольном порядке в произвольном потоке.

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

Независимо от стоимости копирования, для меня было бы хорошей идеей сделать копию simulation data для каждого создаваемого мной потока, или процессор будет работать с несколькими потокамичитаете этот ресурс?Как это изменится, если в стеке будет simulation data.

1 Ответ

0 голосов
/ 18 сентября 2018

Похоже, у вас классическая очередь для одного писателя / нескольких читателей.Существует несколько стратегий синхронизации: RW-lock и Буферы с кольцевым кольцом

Наличие одной копии - определенно лучшая стратегия из-за кэширования.В современных архитектурах записи очереди будут считываться в кэш, например, L3 первым потоком.Последующие потоки на одном и том же процессоре позволят избежать повторного чтения памяти из ОЗУ.В кеше может быть несколько копий записи очереди в нескольких процессорах.

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

Будет плохой идеей сделать несколько копий для каждого потока.Копии будут устаревать кеш, даже если эти данные точно такие же.

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

...