Что делать дальше с DeadlockDetection?
DeadlockDetection — довольно полная утилита, и я успешно применял ее для прослеживания нескольких многопоточных блокировок. Как всегда, однако, читателю рекомендуется искать пути расширения DeadlockDetection, чтобы сделать ее более полезной. Вот некоторые из возможных идей:
- создайте автономное приложение для манипуляций с файлом DEADLOCKDETECTION.INI. Ваша программа могла бы даже улучшиться, если бы она разрешила вам устанавливать DeadDetExt DLL и проверяла, что выбранный DeadDetExt DLL экспортировал правильные функции;
- можно было бы улучшить оптимизацию функций подключения, если бы они не выполняли никакой регистрации. В этом случае не все значения регистров нужно копировать;
- сейчас DeadlockDetection просто пропускает подключение тех DLL, которые ей известны. Хорошо бы разработать программный механизм, определяющий, какие DLL следует пропускать.
История отладочной войны
Незавершенные транзакции с объединенными СОМ-объектами Сражение
Питер Иерарди (Peter lerardi) рассказал мне об интересной многопоточной ошибке, с которой он столкнулся. Он работал над большим DCOM-проектом,который использовал многопоточную DCOM-службу для координации транзакций базы данных. DCOM-служба управляла транзакциями, создавая пул внут-рипроцессных централизованных СОМ-объектов, которые использовались, чтобы записывать и считывать данные из реляционной системы управления базами данных (RDBMS). Межкомпонентная связь выполнялась через сервер очереди сообщений Microsoft (Microsoft Message Queue (MSMQ) Server). Несмотря на то, что выполнялась явная фиксация транзакций, данные в базу данных не записывались. Однако после 3—5-кратных повторных попыток записи, данные, как по мановению волшебной палочки, наконец появлялись в базе. Очевидно, чрезмерные повторения уменьшали производительность приложения и тот факт, что данные не записывались в базу, был причиной для беспокойства.
Результат
После нескольких тяжелых сеансов отладки Питер нашел, что DCOM-служба выполняла чтение и запись на отдельных, несинхронизированных потоках.
Чтение происходило прежде, чем отдельный экземпляр СОМ-объекта базы данных записывал данные. Такое поведение не было очевидным во время отладочных сессий, потому что отладчик форсировал надлежащее таймирование и синхронизацию. Он в конечном счете решил проблему с помощью маркирования экземпляров объекта в Event Log (журнале регистрации событий).
Урок
Большим уроком, по словам Питера, было то, что в крупномасштабном распределенном приложении, невозможно предполагать, что окружение отладки точно соответствует окружению выпуска. Он решил проблему, добавляя соответствующий код синхронизации и группируя покомпонентные коммуникации, которые первоначально проходили через MSMQ-сервер индивидуально, в одну и ту же транзакцию вместе с записями базы данных, так что сообщения посылались только после фиксации транзакций.
Что касается ошибки Питера, то она объясняется очень просто: циклы операций чтения/записи MSMQ выполнялись намного быстрее, чем в базе данных. Хотя Питер и его команда тщательно планировали и прорабатывали многопо-точность в своем проекте, им все еще не доставало некоторого исходного понимания того, насколько быстрее будут выполняться некоторые операции вне их проекта, в реальном мире.
