C Программирование: Отладка с pthreads
Это происходит от Руби. Здесь есть "неофициальное" руководство по стилю Ruby:
http://www.caliban.org/ruby/rubyguide.shtml#indentation
Реального нет причина того, почему два пробела бьют восемь или четыре. Возможно, это потому, что код Ruby часто имеет более короткие строки, чем Java и C, которые обычно используют четыре?
6 ответов
Valgrind - отличный инструмент для поиска состояний гонки и злоупотреблений API pthreads. Он сохраняет модель доступа к программной памяти (и, возможно, к общим ресурсам) и обнаруживает отсутствующие блокировки, даже если ошибка неопасна (что, конечно, означает, что она совершенно неожиданно станет менее благоприятной в более поздний момент).
Для использования это, вы вызываете valgrind --tool = helgrind , вот его руководство . Также есть valgrind --tool = drd ( manual ). Helgrind и DRD используют разные модели, поэтому они обнаруживают перекрывающиеся, но, возможно, разные наборы ошибок. Также возможны ложные срабатывания.
В любом случае, valgrind сэкономил мне бесчисленные часы отладки (хотя и не все :).
Мой подход к многопоточной отладке похож на однопоточную, но обычно больше времени тратится на фазу обдумывания:
Разработайте теорию относительно того, что может быть причиной проблемы.
Определите, каких результатов можно ожидать, если теория верна.
При необходимости добавьте код, который может опровергнуть или подтвердить ваши результаты и теорию.
Если ваша теория верна, устраните проблему.
] Часто «эксперимент», подтверждающий теорию, - это добавление критической секции или мьютекса вокруг подозрительного кода. Затем я попытаюсь сузить проблему, систематически сокращая критический раздел. Критические разделы не всегда являются лучшим исправлением (хотя часто могут быть быстрым исправлением). Однако они полезны для определения «дымящегося пистолета».
Как я уже сказал, те же шаги применимы и к однопоточной отладке, хотя слишком легко просто перейти в отладчик и заняться им. Многопоточная отладка требует гораздо более глубокого понимания кода, поскольку я обычно считаю, что запуск многопоточного кода через отладчик не дает ничего полезного.
Кроме того, hellgrind - отличный инструмент. Программа Intel Thread Checker выполняет аналогичную функцию для Windows, но стоит намного дороже, чем hellgrind.
Отладка многопоточного приложения затруднена. Хороший отладчик, такой как GDB (с дополнительным интерфейсом DDD ) для среды * nix или тот, который поставляется с Visual Studio для Windows, очень поможет.
Одна из вещей, которая удивит вас при отладке многопоточных программ, заключается в том, что вы часто обнаружите, что ошибка изменяется или даже исчезает, когда вы добавляете printf или запускаете программу в отладчике (в просторечии известный как Heisenbug ).
В многопоточной программе ошибка Heisenbug обычно означает наличие состояния гонки . Хороший программист будет искать общие переменные или ресурсы, которые зависят от порядка. Дряной программист попытается вслепую исправить это с помощью операторов sleep ().
Я обычно использую много точек останова. Если вы на самом деле не заботитесь о функции потока, но заботитесь о ее побочных эффектах, возможно, самое время проверить их прямо перед тем, как он выйдет или вернется в состояние ожидания, или что-то еще, что он делает.
На этапе «обдумывания», прежде чем начинать кодирование, используйте концепцию конечного автомата. Это может сделать дизайн более четким.
printf может помочь вам понять динамику вашей программы. Но они загромождают исходный код, поэтому используйте макрос DEBUG_OUT () и в его определении включите его с помощью логического флага. Еще лучше, установите / сбросьте этот флаг с сигналом, который вы отправляете через kill -USR1. Отправьте вывод в файл журнала с отметкой времени.
также рассмотрите возможность использования assert (), а затем проанализируйте свои дампы ядра с помощью gdb и ddd.