Автоматически проверить некоторые ограничения потоков? (С #)

Question

Наша кодовая база имеет множество ограничений на многопоточность, закодированных в комментариях, таких как:

• Этот класс является поточно-ориентированным (все открытые методы могут быть безопасно доступны из любого потока)
• Должен удерживать блокировку "xyz" для доступа / вызова любых открытых участников
• Должен быть доступен только из потока "xyz" (обычно, но не всегда со ссылкой на поток GUI)
• Эта блокировка должна быть взята после блокировки "xyz", если требуются оба

Первые три можно увидеть как на классах, так и на отдельных участниках.

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

Можете ли вы предложить инструмент, чтобы сделать что-то подобное? Возможно набор правил FxCop, который работает, кодируя вышеупомянутые ограничения как атрибуты?

Answer 1

Мне неизвестны какие-либо атрибуты безопасности потоков, просто потому что они, как правило, слишком сложные. А «тестирование» многопоточного кода (с добавлением лишних Debug.Assert и т. Д.) Является частой причиной появления ошибок. Вы могли бы посмотреть на " ШАХМАТЫ "? Это не серебряная пуля, но это может быть полезно.

Answer 2

Вы можете попытаться реализовать некоторые пользовательские правила FxCop (запускаются с использованием соответствующего атрибута). Это может помочь вам проверить какое-то простое состояние (например, этот класс является поточно-ориентированным, поскольку он не содержит изменяемого состояния).

Другая проверка, вероятно, будет более сложной (например, может ли FxCop проверить, что, когда установлено поле "X", это всегда выполняется, когда мы удерживаем заданную блокировку) - возможно. Если это важно, я бы посоветовал взглянуть на FxCop SDK и посмотреть, насколько сложным будет такой тест.

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

Answer 3

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