.net: отладка потоков

Question

Какие методы доступны для устранения проблем многопоточности в среде .net.

Answer 1

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

Однако вы можете упростить написание многопоточного кода, сделав несколько заметок из функциональных языков программирования:

Использовать неизменные структуры данных:

очень легко писать многопоточный код на F #, Haskell, Erlang, OCaml и т. Д., Потому что структуры данных и значения в этих языках неизменны, что означает, что вы не можете изменять переменную после ее назначения. По сути, это означает, что каждая переменная объявлена ​​константой, и нет таких методов, как List.Add или Dictionary.Add, которые изменяют коллекцию.

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

Положитесь на передачу сообщений для обмена данными между процессами Прочитайте эти сообщения в блоге:

• http://www.defmacro.org/ramblings/concurrency.html
• http://en.wikipedia.org/wiki/Erlang_(programming_language)#Concurrency_and_distribution_oriented_language

Erlang - замечательный язык, особенно потому, что его модель параллелизма масштабируется до 1000 и 1000 компьютеров. Вместо того, чтобы предоставлять потокам доступ к общему состоянию, он использует передачу сообщений для передачи информации из одного потока в другой.

Использование каналов для синхронизации потоков Вот хорошее видео на языке Newsqueak: http://video.google.com/videoplay?docid=810232012617965344

Он описывает интересный подход Newsqueak к параллелизму. Он использует объекты, называемые «каналами», для передачи данных из одного потока в другой. Легко найти C # реализации каналов.

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

Answer 2

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

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

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

Проверка уровня блокировки работает следующим образом: предположим, у вас есть 3 блокировки - A, B и C. Вы даете им уровни 1, 2 и 3 соответственно. Если поток всегда запрашивает блокировку более низкого уровня перед блокировкой более высокого уровня, то вы никогда не попадете в ситуацию, когда один поток может запросить A, затем B, в то время как другой запрос B, а затем A. Чтобы реализовать проверку уровня блокировки, присвойте каждому свой замок возражает уровень. Используйте локальное хранилище потока, чтобы поток знал, какой уровень блокировки он использовал в последний раз. Фактически, объект стека находится в локальном хранилище потока, поэтому при снятии блокировки вы знаете уровень предыдущей блокировки. Некоторые приложения утверждают, что замки уже принадлежат им. Это безопасно. Чтобы учесть это в контроллере блокировки потока, вам нужно отсканировать стек блокировок, чтобы увидеть, был ли он уже востребован.

Вся эта проверка уровня блокировки влечет за собой снижение производительности. Так что, скорее всего, это подойдет только для отладки или специальной сборки.