не-не-не, отладчиком ловить глюки многопоточности — дохлый номер, времени уйдет вагон, а пользы мало. Для этого есть другие инструменты.
Разве что под "отладчиком" понимать tracing debugger, который просто пишет все в логи, а потом эти логи можно проигрывать (replay) детерминированным образом. Но это уже не совсем отладчик (хоть и выглядит таковым), а, скорее, продвинутый log viewer. В сложных и распределенных системах, впрочем, это один из немногих работающих и удобных инструментов (жаль что мало где реализован).
Здравствуйте, SkyDance, Вы писали:
S>>В отладчике потоки можно оттормаживать SD>не-не-не, отладчиком ловить глюки многопоточности — дохлый номер, времени уйдет вагон, а пользы мало. Для этого есть другие инструменты.
Воспроизводить, а не ловить. Банально быстрее посмотреть, что два потока работают непотокобезопасно с разделяемыми данными,
чем вчитываться в код, котороый еще может быть и легаси и т.п.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, SkyDance, Вы писали:
S>>>В отладчике потоки можно оттормаживать SD>>не-не-не, отладчиком ловить глюки многопоточности — дохлый номер, времени уйдет вагон, а пользы мало. Для этого есть другие инструменты.
S>Воспроизводить, а не ловить. Банально быстрее посмотреть, что два потока работают непотокобезопасно с разделяемыми данными, S>чем вчитываться в код, котороый еще может быть и легаси и т.п.
Т.е. именно, когда ошибку локализовал, и сейчас уже с пинцетом (отладчиком) разбираешся в нюансах (тупо чинишь уже, грубо говоря).
Но чтобы локализовать эту ошибку (не воспроизвести, а именно локализовать) в многопоточном окружении, отладчик только помешает.
S>Воспроизводить, а не ловить. Банально быстрее посмотреть, что два потока работают непотокобезопасно с разделяемыми данными,
Это слишком сложно (порой и невозможно) посмотреть в дебаггере на живом (реальном) коде, потому что там все равно есть недетерминизм (os scheduling иначе сработает, или таймер не в ту микросекунду тикнет). Поэтому "дебажат" не в реалтайме, и не саму программу, а трейсы.
И вообще для многопоточности и распределенных систем лучше пользоваться другим инструментарием. В первую очередь моделированием и model checking.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Иногда отладчик и загончик тоже помогает огородить. Не будешь же ты вообще все состояние вываливать в логи, верно?
"Случаи, корнет, разные бывают-с" (С)
В любом случае инструмент выбирается под задачу. И лучше когда есть возможность выбора из разных инструментов, чем только один.
Здравствуйте, CreatorCray, Вы писали:
L>>Воот. Отладчик — это тонкий инструмент. И использовать его нужно по назначению CC>А что, с этим кто то спорит?
Так хотя бы в соседней подветке про гнездо багов в многопоточной программе.
Здравствуйте, SkyDance, Вы писали:
SD>Это слишком сложно (порой и невозможно) посмотреть в дебаггере на живом (реальном) коде, потому что там все равно есть недетерминизм (os scheduling иначе сработает, или таймер не в ту микросекунду тикнет). Поэтому "дебажат" не в реалтайме, и не саму программу, а трейсы.
Я говорил про свой, относительно простой, опыт на платформе .net с отладчиком vs. Когда мне прилетел с прода странное
исключение из-за проблем добавления эл-та в коллекцию, которого при однопоточном варианте быть не должно. Взял отладчик,
походил потоками, довел до ситуации, когда несколько потоков работают без синхронизации с непотокобез. структурой данных.
Race condition? Race condition. Проблема найдена, добавил соотв. синхронизацию. Можно было вчитывать в логику, кот. и так
не тривиальна, а еще держать в уме, что параллельно работает несколько других потоков. А можно просто взять отладчик и за\
10-15 минут потвердить свои догадки и решить проблему.
SD>И вообще для многопоточности и распределенных систем лучше пользоваться другим инструментарием. В первую очередь моделированием и model checking.
А ну а если их нету? И я вовсе на настаиваю на отладчике как сереберяной пуле. Просто в моем случае он был мне полезен, что
никак не отменяет др. подходов и инструментов.
S>Взял отладчик, S>походил потоками, довел до ситуации, когда несколько потоков работают без синхронизации с непотокобез. структурой данных.
Такое обычно достижимо только для совсем тривиальных случаев, которые видно в коде, если его внимательно прочитать (eagle's eye debugging).
S>А ну а если их нету?
Да даже если есть, первым делом нужно написать тест, который будет воспроизводить проблему. Потому что если баг будет пофикшен без добавления теста, можно дать гарантию, что он появится снова на следующей итерации разработки продукта.
Лично для меня дебаггер является удобным способом смотреть логику работы совсем уж незнакомой программы (с помощью step into обнаруживать всякую магию вроде спрятанных вызовов, двойной диспетчеризации и т.п.).
Здравствуйте, Sharov, Вы писали:
S>Я говорил про свой, относительно простой, опыт на платформе .net с отладчиком vs. Когда мне прилетел с прода странное
Соглашусь со SkyDance.
Если подобный код в принципе попадает в прод, то... ну плохи дела, в общем.
Проблемы многопоточности всегда лежат в плоскости логики/архитектуры (ну и исчезающе мало приходится на какую-нибудь забавную эзотерику вроде вроде "мы забыли volatile, а компилятор и правда оптимизировал все в ноль").
Как правило, попытки "починить" кривой многопоточный код с помощью отладчика заканчивается втыканием мьютексов куда попало со всеми радостями вроде дедлоков (но реже) и переносом бага в другое место. Или превращением программы в однопоточную, т.к. все потоки все время ждут одного.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
S>Каково ваше отношение к данной идее?
Мне о том, что программировать надо без отладчика всегда рассказывали фанаты редактора vim, когда я интересовался когда же там наконец-то появится нормальная интеграция с отладчиком.
Отладчиком пользоваться можно и нужно. Это полезный инструмент, который реально помогает разобраться в коде, и экономит время.
С другой стороны, надо понимать, что отладчик далеко не везде может помочь, он может оказаться бесполезен или даже вреден. Поэтому умение дебажить прогу без отладчика довольно полезно, ну и вообще привычка немного подумать прежде чем запускать отладчик, тоже довольно полезна.
L>Если подобный код в принципе попадает в прод, то... ну плохи дела, в общем. L>Проблемы многопоточности всегда лежат в плоскости логики/архитектуры (ну и исчезающе мало приходится на какую-нибудь забавную
Ой, ладно. В реальности был написан код, который был рассчитан на 1 поток. В целях ускорения произв-ти я добавил
многопоточность, долгим и внимательным чтением кода нашел все места, где надо добавить синхронизацию, но оказалось, что
что-то продолбал. Жизненная ситуация, переписывать код -- не вариант.
L> эзотерику вроде вроде "мы забыли volatile, а компилятор и правда оптимизировал все в ноль").
volatile, к слову, вообще не про это. В шарпе, как минимум.
L>Как правило, попытки "починить" кривой многопоточный код с помощью отладчика заканчивается втыканием мьютексов куда попало со всеми радостями вроде дедлоков (но реже) и переносом бага в другое место. Или превращением программы в однопоточную, т.к. все потоки все время ждут одного.
Я не говорил починить, я говорил, что взял в руки отладчик и воспроизвел проблему, кот. в однопоточном коде
скорее всего в принципе быть не должно -- добавление-удаление эл-та в коллекцию. А чтобы не было дедлоков, надо
внимательно читать код или знать его хорошо.
Еще раз -- прилетает ошибка, которая в однопоточном коде практически не реальна (см. выше),
остается проверить многопоточный сценарий -- запустил тест, походил потоками под отлдакой и добился возникновения проблемы,
т.е. race condition. Все, подтвердил свои догадки. В чем тут проблема?
