Отладка многопоточных приложений

Получив в очередной раз трудновоспроизводимый баг в жутко многопоточном окружении, начинаешь задумываться - а как бы упростить себе жизнь? Как бы сделать так, чтобы такие баги было гораздо проще поймать?
Ведь обычно такие баги прячутся очень хорошо - они могут проявляться раз в год на нормальной машине, но на определенных компьютерах вдруг они начинают вылезать каждые 5 минут. Например, так часто бывает на медленных компьютерах - на них баги с многопоточностью вылезают особенно часто.


И сегодня мне в голову пришла интересная идея. А что если бы в ядре ОС у планировщика потоков была возможность “эмуляции” стресс тестирования для потоков? Это бы очень сильно упростило жизнь разработчикам.
Я имею в виду, например, чтобы планировщик давал потокам минимальные окна для работы, плюс чтобы эти окна были случайные.
Ведь в чем проблема с медленными компьютерами? В том, что на быстрых определенный код успевает обычно отработать до переключения потоков, а на медленных - не успевает. Потом в другом потоке что-то удаляется или блокируется и, когда управление возвращается обратно - происходит баг. Это один из основных сценариев.
И если бы планировщик потоков мог бы рандомизировать переключения потоков, то программисты бы могли все такие ситуации тестировать на своих машинах, а не на машинах пользователей.
Вообще, можно придумать много сценариев работы для планировщика, которые могли бы помочь в тестировании и отладке и проблема только одна - даже если я придумаю их сто штук, я не смогу их реализовать.


И вот тут все любители Linux должны воскликнуть “Ага!”. И точно - “ага”!
В Linux любой может залезть в ядро и поменять алгоритм работы планировщика потоков. Так что можно будет собрать специальное ядро для тестов и тестировать на нём.
У разработчиков для Windows и MacOS такой возможности нет и остается только ждать милости “гигантов”…


Понравилась статья? Подпишись на RSS!

41 комментариев к Отладка многопоточных приложений

  • Yorik

    И ещё можешь почитать http://antilamer.livejournal.com/279512.html для общего интереса и развития

  • Почему у разработчиков Windows нет такой возможности? Никто не мешает написать свой драйвер шедулера. Под Windows CE это точно возможно. Под Win Vista нужно подробнее смотреть - возможно есть какая-то защита от левых драйверов.

  • Конечно иметь возможность воспроизвести баг - это уже хорошо… то есть типа потенциальная возможность воспроизведения. Можно всякой отладки, бряков напихать и ждать…

    Но было бы гораздо лучше - если воспроизводимость ошибки приближалась к 100%… Чтобы не сидеть и не ждать пока повезет. :)

    Вообще нельзя в таком ответственном деле уповать на случай. :) Поэтому генератор случайных чисел - фтопку. Лучше фиксированные значения.

  • helgrind из состава valgrind часто помогает найти такие баги…

  • Microsoft Application Verifier это случайно не то, что нужно?

    Описание

    Среди тестов есть такие:

    Low resource simulation tries to simulate an environment under low resources, whereby you can define a number (0–100) that indicates the fault probability calls of:
    * Wait (for example. the WaitForXXXX API).
    * Heap_Alloc (Heap Allocation API).
    * Virtual_Alloc (Virtual Memory allocation API).
    * Registry (Registry API).
    * File (File API such as CreateFile).
    * Event (Event API such as CreateEvent).
    * MapView ( MapView API such as CreateMapView).
    * Ole_Alloc (Ole API such as SysAllocString).

  • shks57

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

  • Eugene

    Гиганты смилостивились и сделали Chess: http://research.microsoft.com/en-us/projects/chess/

  • Eugene

    майкрософт сделали сhess, можно найти на technet

    • Eugene

      Смысл тулзы как раз в том, чтобы по-разному шедулить потоки, создавая всевозможный интерливинг.
      Ну и предполагается, что под ней будут работать “юнит”-тесты.

    • Chess - другое. Это типа юнит тестинга для потоков. С ним надо строить приложение и писать спец. тесты.

  • D

    Ядро в OS X вполне себе opensourced

  • ADEpt

    А еще можно писать так, чтобы баги, связанные с нарушением синхронизации не появлялись вообще :)

    (барабанная дробь, входит Haskell. В руках у него книжка Hoare, в рюкзаке - STM (software transcational memory))

    • А еще можно писать так, чтобы баги вообще не появлялись. Не только связанные с синхронизацией, а вообще… Кто-то в это верит?

      • можно по крайней мере радикально сократить их количество, если писать не на ассемблере-переростке :-)

        • Это факт, да. Писать на С или “С с классами” в 21 веке - нонсенс. Однако же до сих пор самые критические приложения на них пишутся…

          • по моему опыту - это в основном инертность мышления, а ни какая-то необходимость… а опыт у меня достаточно наглядный

            • >> по моему опыту - это в основном инертность мышления, а ни какая-то необходимость…

              Не всегда. Если С используется для создания простых коммерческих тулзов или гуишных приложений - безусловно.
              Но есть еще сферы, где C почти стандарт, а не Java или .Net, не говоря уже о Lisp. И там это пока не меняется - это высокопроизводительные вычисления. Типа игр или антивирусов. Или драйвера.

              • я сам пишу софт для безопасности, и вижу, что во многих местах С++ излишне усложняет разработку. Критические (в части скорости) части можно написать на C/C++, а основную логику - на чем-то другом, более безопасном

                • Это если можно выделить такие “некритические части”.
                  Например, у нас на С++ не пишутся всякие тесты, простые тулзы и т.п. - для этого python или другой скриптовый язык отлично подходит.
                  Но когда дело доходит до чего-то, что должно работать у кастомера в составе продукта - тут уже сразу строго только C++. Даже гуи на C++.
                  Хотя я бы может часть продукта и написал на другом языке - ГУИ, тулзы, вспомогательные компоненты. Но опять же проблема - если в компании пишут на С, то ВСЕ пишут на С. А значит на Java или .Net даже тулзов не написать - их тупо почти никто не знает :) Так что это ловушка.

              • да и насчет игрушек - я, насколько помню, кто-то из популярных леталок был написан на Яве

                • Да, в IL-2 штурмовике было что-то на яве написано. Какая-то часть. А в рейнджерах на Delphi логику писали. Каждый пишет на том, что ему ближе, но всё равно 95-99% в геймдеве до сих пор - С++.

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

                • SS

                  Это что то может быть например загрузчиком скриптов или еще чего то что делается один раз в игре при загрузке и где производительность не имеет значения…

  • Eugene

    Не понял, у вас коментарии премодерируются или какой-то двудневный лаг между отправкой и их появлением? пытался несколько раз отправить в первый день, и только 4я чтоли попытка удалась. А теперь вижу их все идущими подряд

    • Это антиспам фильтр так работает - он подозрительные сообщения отправляет мне на модерацию. Обычно те, где есть ссылки, считает подозрительными. А я не так часто в список подозрительных захожу, чтобы отфильтровать - уж больно много спама приходит.
      Но такой фильтр лучше, чем его отсутствие - иначе бы по 5-10 спам-комментов в день приходило.

  • А еще есть Intel Parallel studio, судя по презентации на techdays.ru это именно то, что доктор прописал.

  • SS

    У Intel и до этого были тулзы для этих и др. целей… типа Intel VTune только для потоков как то по другому называется…

  • SS

    А вообще, нормальный код и при многопоточности работает без проблем!
    Отладьте все что крутится в потоке, проверьте логику синхронизации и проблем не дожно быть.
    Для тестирования на “коленке” (имитация медленной машины) в голову приходит задать низкие приоритеты рабочим потокам и запустить поток с высоким приоритетом и циклом который будет бегать ничего не делая и грузить процессор.
    По поводу имитации схемы работы или повторения не воспроизводимого стабильно бага, скажу у самого несколько таких проектов, в которых огромное количество путей в зависимости от постоянно идущих входящих данных/параметров и выбор ветки и обработки в зависимости от них и постоянно меняющихся внутренних данных. Ну и конечно все работает паралельно с большим, произвольным количеством потоков. Баг всегда удавалось выловить путем анализа и протоколирования хотя бы части данных, хоть раз да попадет набор данных с которым баг проявляется. Хотя повторюсь в 95% случаев найденная бага никакого отношения к многопоточности не имеет а скорее из-за модели которая с ростом стала слишком сложной для понимания и контроля… т.е. рефакторинг убрал бы сразу 80-90% ошибок. Но проект старый, все всё позабывали и трогать не хотят.

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

      Было бы все так просто :) Я сейчас склоняюсь в сторону стресс тестов для тестирования многопоточности. Пишу специльные тесты, в которых гоняю в максимально напряженном режиме код с кучей потоков и на каждой строчке кода вставляю рандомный Sleep. В итоге все возможные варианты переключения потоков за день-два происходят и все баги находятся и фиксятся.
      Потом этот стресс тест добавляется в тест аутомейшен и вуаля - защита от будущих багов :)

Ответить

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>