Недостатки разделяемой памяти в многопоточных проектах

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

Схема примерно такая: структура данных алгоритма хранится в 1 месте в памяти в виде экземпляров классов. Примером задачи, которую можно выполнить в этой структуре, является вставка нейрона: она изменит несколько значений в нейроне и связанных нейронах и определит любые будущие задачи, которые могут потребоваться для выполнения. Задачи, которые необходимо выполнить, добавляются в очередь. Существует несколько потоков, единственной функцией которых является извлечение задачи из очереди, выполнение задачи и последующее повторение. Любые обновления значений могут выполняться в любом порядке, пока они выполняются. Небольшие, но редкие ошибки, возникающие в результате такого параллелизма, окажут статистически незначительное влияние на производительность системы.

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


person Alex Londeree    schedule 15.06.2011    source источник
comment
Кстати, вы изучали Erlang и другие языки моделей акторов? en.wikipedia.org/wiki/Actor_model   -  person HostileFork says dont trust SE    schedule 15.06.2011
comment
Я не уверен, действительно ли вы понимаете (или имеете в виду) общую память. Вы не можете создать по-настоящему масштабируемую (сотни ядер) систему, не используя никакой другой памяти, кроме общей памяти. В основном вы хотите читать в общей памяти, но как можно меньше обновлений. Трудно представить, что будет, если все ядра попытаются обработать одну и ту же строку кэша...   -  person bestsss    schedule 17.06.2011


Ответы (1)


Доступ к общему состоянию из нескольких потоков в многоядерной системе может быть медленным из-за протокола когерентности кэша ЦП. То есть каждое изменение общего состояния должно отражаться в строках кеша всех ядер.

http://msdn.microsoft.com/en-us/magazine/cc163715.aspx#S2 хорошо объясняет, почему доступ к общим данным из нескольких потоков может быть медленным и что с этим можно сделать.

person Vadym Stetsiak    schedule 16.06.2011