У меня снова глупый вопрос про многопоточность. Как известно многопоточный код чреват многими ошибками которые не актуальны при однопоточном программировании. К тому же они весьма трудно уловимы. Часто бывает трудно искусственно смоделировать какой-либо баг который то появляется то исчезает при работе приложения потому что сложно предсказать как именно и когда именно два разных потока обратятся к данным так что это приведет к порче данных. К тому же у меня наверное еще не очень хорошо развито умение выискивать проблемные с точки зрения многопоточности места в коде. А теперь вопрос: есть ли какие-то рецепты как обнаруживать потенциальные проблемы многопоточного доступа к данным? Вот например блокировки lock. Есть ли какие-то верные признаки по которым можно было бы сказать что вот в этом коде использующем многопоточность нужен lock а вот тут не нужен? Особенно с учетом того что баги связанные с использованием потоков часто бывает трудно отловить? Как вообще локализуются такие проблемы при написании кода и как они отлавливаются при дебаге?
Ответ
Первое правило многопоточности - не используйте многопоточность :)
Блокировки и прочие види синхронизации нужны для разделения доступа к ресурсам из разных потоков. Использование одного и того же объекта (не класса, а именно объекта) всегда требует явной или неявной блокировки/синхронизации.
Потенциально проблемные места:
Явная статика
Неявная статика (использование Singleton в коде, любые вызовы вида SomeClass.Instance)
Явные (параметрами) или неявные (через замыкания) переданные в фоновые потоке объекты.
Основные принципы починки проблемных мест:
Переход на классы, явно поддерживающие многопоточность. Например, проблема из вашего соседнего вопроса решается заменой линейного поиска перебором List
Комментариев нет:
Отправить комментарий