Потоковая отладка в C # и vs2008 - PullRequest
5 голосов
/ 18 июня 2009

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

  1. Основной поток для обновления пользовательского интерфейса. Пользователь может изменить один параметр устройства или сразу несколько, выбрав предустановку.
  2. Поток проверки состояния, который запрашивает, чтобы убедиться, что устройство все еще подключено. Если пользователь выключает устройство или само устройство взаимодействует интересным образом, изменения статуса должны быть отражены в пользовательском интерфейсе.
  3. Поток, считывающий последовательный порт, на который отвечает устройство.

Моя проблема на самом деле связана с отладкой этой ситуации. Кажется, что каждая отдельная строка в каждом потоке должна иметь точку останова для отладки; если я нарушу один поток, отладчик не будет проходить через этот поток. Я понимаю, что другие потоки будут продолжать обновляться, но не должен ли поток, в котором я работаю, выполняться как обычно в отладчике, то есть переходить от одной строки к другой? Затем я мог бы использовать вкладку «Потоки» для переключения между потоками.

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

Ответы [ 3 ]

7 голосов
/ 18 июня 2009

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

Вы можете заморозить другие темы при отладке

Когда вы находитесь в точке останова, выберите Debug | Windows | Темы . Выберите темы, которые вам не интересны, и щелкните правой кнопкой мыши, выберите Freeze . Это позволит вам сосредоточиться на том, через который вы проходите.

1 голос
/ 20 июня 2009

Я с Джейсоном, степпинг больше не покажет правду.

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

Счетчик необходим, потому что порядок фактических событий не всегда совпадает с порядком записи в файл. Назовите потоки или используйте значение ID в выходных данных. Я использую MS Excel, чтобы открыть файл и раскрасить все строки в зависимости от потока, так я очень четко вижу операции чередования.

Я даже написал оболочку для блокировки {}, какие инструменты при каждой блокировке включаются / выключаются.

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

Не забудьте использовать volatile в случае необходимости с IO.

1 голос
/ 18 июня 2009

Если ваш код странным образом пошагово, иногда это может быть вызвано простым испорченным файлом pdb. «Перестроить все» в вашем коде сгенерирует его с нуля и излечит любые подобные проблемы.

Еще одна вещь, которую следует иметь в виду, это то, что остановка одного потока в отладчике может вызвать все виды необычного времени, которое вы не увидите в сборке релиза. Например:

  • Последовательный порт всегда будет продолжать работать (на уровне аппаратного обеспечения / драйвера), пока вы остановились на точке останова - когда вы в следующий раз попытаетесь выполнить шаг своего кода, он может получить внезапный огромный поток данных. С асинхронными обратными вызовами это может быть «интересно».

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

...