Читать онлайн «Кодеры за работой. Размышления о ремесле программиста». Страница 61

Есть и другие - способные выжать из языка все, что возможно, ради большей эффективности. Надо найти им нужное применение - они будут счастливы и принесут пользу вашей компании. Вообще, необходимо знать сильные места ваших разработчиков и пользоваться этим. Это я так оправдываюсь за свое плохое знание инструментов. Слабое оправдание, понятно.

Сейбел: Поговорим об отладке. Можете ли вы назвать худшую ошибку из тех, что вам встречались?

Блох: Мне сразу приходит в голову один кошмарный и в то же время любопытный случай. Это было в начале 1990-х, я тогда работал в питт-сбургской компании Transarc. Мне пришлось заниматься реализацией транзакционной разделяемой памяти при очень плотном графике. Проектирование и реализацию я закончил в срок и даже успел написать несколько библиотечных компонентов. Но я нервничал из-за того, что произвел много нового кода в спешке.

Для тестирования кода я написал чудовищного “убийцу”. Он запускал множество транзакций, каждая из которых содержала рекурсивно вложенные транзакции - вплоть до определенной глубины вложения. Каждая из вложенных транзакций могла блокировать и читать некоторые элементы разделяемого массива в восходящем порядке и что-то прибавлять к каждому из них, сохраняя инвариант, так что сумма всех элементов массива равнялась нулю. Каждая субтранзакция либо фиксировалась, либо прерывалась - соотношение случаев было 90:10, как-то так. Множество потоков запускали эти транзакции параллельно и воздействовали на массив в течение долгого времени. Поскольку я тестировал разделяемую память, то запускал несколько многопоточных “убийц”, каждый в своем собственном процессе.

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

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

Я написал собственный диспетчер блокировок, поэтому стал подозревать его. Но ведь он без проблем прошел модульные тесты! Наконец я определил, что виноват был не он, а реализация мьютексов в нижележащем слое. Тогда операционные системы еще не поддерживали многопоточность, и пакет для ее поддержки нам пришлось писать самим. Вышло так, что разработчик, отвечавший за код мьютексов, случайно перепутал метки подпрограмм “заблокировать” и “попробовать заблокировать” в ассемблерной реализации потоков в Solaris. Так что каждый раз, когда вы думали, что вызываете безусловную блокировку, на самом деле она только пыталась произойти, и наоборот. И когда случался конфликт - в то время редкость, - второй поток оказывался в критической секции, как если бы в первом потоке не было блокировки. Самое забавное, что вся компания на несколько недель оказалась без мьютексов, и никто не заметил.

В своей превосходной статье “Engineering a Sort Function” (Разработка функции Sort) Бентли и Макилрой цитируют чудесное высказывание Кнута насчет приведения себя в самое поганое настроение, на которое только вы способны. Как раз это я и сделал для той серии тестов. Но это сделало ошибку крайне трудно обнаружимой. Прежде всего, из-за многопоточности каждый случай оказывался почти невоспроизводимым. Далее, оказались ложными мои представления не о чем-нибудь, а о ядре системы. Обычно начинающие программисты легко приходят к выводу, что язык или система не в порядке. Но тут базовая конструкция, на которую я опирался, - мьютекс - действительно оказалась сломанной.

Сейбел: Итак, ошибка содержалась не в вашем коде, но вы тем временем написали столь подробные тесты для кода, что ошибку волей-неволей пришлось искать вне его. Как по-вашему, мог ли - или должен ли был - автор мьютексов написать тесты для нахождения этой ошибки, которые избавили бы вас от полутора недель отладки?

Блох: Мне кажется, хорошая автоматическая программа проверки мьютексов спасла бы меня от мучений, но не забудем, что это было в начале 1990-х. Мне и в голову не приходило винить разработчика за то, что он не создал достаточно хороших модульных тестов. Даже сегодня писать модульные тесты для многопоточных программ - подлинное искусство.

Сейбел: Мы говорили о пошаговом прохождении кода. А какими средствами отладки вы пользуетесь сейчас?

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

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

Я уже говорил, что пользуюсь операторами утверждения для проверки сохранности сложных инвариантов. Если инварианты ломаются, я хочу знать, когда это случилось, какие действия привели к этому.

Кстати, я вспомнил еще одну труднонаходимую ошибку. Правда, не могу сказать точно, было это в Transarc или на последнем курсе Университета Карнеги-Меллона, когда я работал над системой распределенных транзакций Camelot. He я нашел эту ошибку, но сам случай меня глубоко поразил.

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

Но выяснилось, что ошибка не в трассировочном пакете - все было гораздо серьезнее. Чтобы найти идентификатор потока, трассировочный пакет вызывал код из потоковой библиотеки. А тот делал штуку, очень в то время распространенную: смотрел старшие биты адреса стековой переменной. То есть он брал значение указателя стековой переменной и сдвигал его вправо на фиксированное число позиций, получая таким образом идентификатор потока. Дело в том, что у каждого потока был стек определенного размера, который выражался заранее известной степенью двойки.