Как найти блокировку (читатель) моего ReaderWriterLock в windbg

Question

У меня есть дамп процесса .Net, который завис из-за тупика (поток графического интерфейса больше не отвечает, и мои журналы показывают, что некоторые потоки перестали отвечать). Я сделал снимок и сейчас просматриваю его в windbg, и все нити в баре ожидают последнего. Глядя на трассировку стека этого потока с помощью! Clrstack -p, я вижу, что он пытается получить запись на ReaderWriterLock

Как мне узнать, какой другой поток удерживает эту блокировку, чтобы я мог выяснить, как произошла тупиковая ситуация?

спасибо

[править], очевидно, в .Net1.1 sos.dll была команда! Rwlocks, чтобы помочь с этим, но ее нет в версии .Net2.0. Охота продолжается

Answer 1

Я недавно опубликовал симуляционную тему здесь, Используя C #, можно проверить, удерживается ли блокировка для файла

Я ссылался на несколько статей и тому подобное, но обход цепочки ожидания (WCT) может вам помочь, это несколько обидно, но эта статья msdn mag bugslayer показывает, как использовать WCT в windbg в управляемом контексте.

Answer 2

Попробуйте sosex и! Dlk

Answer 3

Я не совсем уверен, но вы можете использовать! SyncBlk для просмотра объектов блока синхронизации, если вы вызываете его без каких-либо аргументов, я думаю, вы должны увидеть блоки синхронизации, принадлежащие потоку.

Если у вас есть взаимоблокировка блока синхронизации, расширение SOSEX может быть тем, что вам нужно. Это расширение предлагает команду! Dlk, которая показывает, какие потоки ожидают каких блокировок. Это работает только для блоков синхронизации, однако, взаимные блокировки других объектов синхронизации не будут обнаружены, если вы используете lock () (Monitor.Enter), это не должно быть проблемой для вас.

Answer 4

Подход, который обеспечил бы отслеживаемость, заключается в том, чтобы обернуть ваши блокировки в интерфейс IDisposable и заменить:

блокировка (mylock) {...}

с

с использованием (new DisposeableLock ()) {...}

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

Answer 5

Пока что лучший подход - это посмотреть! Dso для всех стеков потоков и посмотреть, какие из них ссылаются на блокировку. Быстрая проверка после этого позволяет нам отследить, какие потоки удерживают блокировки. Хотя на самом деле это не очень хороший или быстрый способ ...