Методы отладки и тестирования многопоточных приложений

#отладка #c #многопоточность #unix

Расскажите, пожалуйста, о способах отладки и тестирования многопоточных приложений.

Есть ли у вас какие-то любимые, проверенные методики, может утилиты, которые будут
полезны (исключая уже много раз мною упомянутый Valgrind)? 

На что при тестировании следует обратить особое внимание? 

В общем всё, что подойдет относительно начинающему. Работаю в Freebsd с posix_thread.
    

Ответы

Ответ 1

@margosh, я тупо ставлю printf-ы в которых обязательно печатаю еще и thread id. Если
прога падает (SIGSEGV и т.п.) смотрю gdb. Он сообщает в каком потоке свалилось.
Вообще, все более-менее нетривиальные функции стараюсь сначала отладить в однопоточном
варианте (просто из main). 
Многопоточную логику сначала выделяю в некие тестовые куски (без реального наполнения
данными задачи) и просто играюсь с ней (опять printf-ами, слипами, где-то ввод с клавиатуры
и запись в какой-нибудь пайп и т.д.).
Ну, и черкаю ручкой на бумаге линии потоков, какие события и когда происходят и т.п. 
--
В целом так, но реально я иногда просто вижу алгоритм в виде каких-то цветных и объемных
фигурок, которые двигаются, сливаются, меняются ... и тогда мне  становится ясно, как
это можно программировать.


Ответ 2

Unit и Integration тесты еще никто не отменял, причем они работают вне зависимости
от того, производилась ли параллелизация сразу же или же вы сначала реализовали однопоточный
вариант функции, а лишь затем распаралелили его.

Единственный минус - поднять более-менее адекватную тестовую среду для мультитредового
приложения или его мультитредовых блоков - это задача на порядок сложнее аналогичной
задачи для single-core environment.
И да, Valgrind, а именно DRD вполне себе неплохо справляются с поставленной задачей.
Мне, конечно, средства под Windows кажутся более интуитивными, но, как говорится -
на вкус и цвет.


Ответ 3

Могу в дополнение порекомендовать 

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