Блокировка потоков в больших параллельных приложениях

#multithreading #architecture #parallel-processing

#многопоточность #архитектура #параллельная обработка

Вопрос:

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

Какова наилучшая практика по управлению потоками, «контекстам синхронизации» и т.д. в больших приложениях? Кажется, единственное надежное решение — расширить возможности приложения синхронизации данных, чтобы данные могли безопасно использоваться любым объектом в любое время, но это, похоже, нарушает концепции объектно-ориентированного кодирования.

Как лучше всего решить эту проблему?

Ответ №1:

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

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

Комментарии:

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

2. _ Существуют ли какие-либо допустимые шаблоны, в которых объекты блокировки являются общедоступными?