Программирование. Принципы и практика использования C++ Исправленное издание

Страуструп Бьерн

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

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

• Предотвращение

утечки ресурсов. Не допускайте утечек. Старайтесь точно знать, какие ресурсы использует ваша программа, и стремитесь их экономить (в идеале). Любая утечка в конце концов выведет вашу систему или подсистему из строя. Самыми важными ресурсами являются время и память. Как правило, программа использует и другие ресурсы, например блокировки, каналы связи и файлы.

• Дублирование. Если для функционирования системы крайне важно, чтобы какое-то устройство работало нормально (например, компьютер, устройство вывода, колесо), то перед проектировщиком возникает фундаментальная проблема выбора: не следует ли продублировать критически важный ресурс? Мы должны либо смириться со сбоем, если аппаратное обеспечение выйдет из строя, или предусмотреть резервное устройство и предоставить его в распоряжение программного обеспечения. Например, контроллеры топливных инжекторов в судовых дизельных двигателях снабжены тремя резервными компьютерами, связанными продублированной сетью. Подчеркнем, что резерв не обязан быть идентичным оригиналу (например, космический зонд может иметь мощную основную антенну и слабую запасную). Отметим также, что в обычных условиях резерв можно также использовать для повышения производительности системы.

• Самопроверка. Необходимо знать, когда программа (или аппаратное обеспечение) работает неправильно. В этом отношении могут оказаться очень полезными компоненты аппаратного обеспечения (например, запоминающие устройства), которые сами себя контролируют, исправляют незначительные ошибки и сообщают о серьезных неполадках. Программное обеспечение может проверять целостность структур данных, инварианты (см. раздел 9.4.3) и полагаться на внутренний “санитарный контроль” (операторы контроля). К сожалению, самопроверка сама по себе является ненадежной, поэтому следует опасаться, чтобы сообщение об ошибке само не вызвало ошибку. Полностью проверить средства проверки ошибок — это действительно трудная задача.

• Быстрый способ выйти из неправильно работающей программы. Составляйте системы из модулей. В основу обработки ошибок должен быть положен модульный принцип: каждый модуль должен иметь свою собственную задачу. Если модуль решит, что не может выполнить свое задание, он может сообщить об этом другому модулю. Обработка ошибок внутри модуля должна быть простой (это повышает вероятность того, что она будет правильной и эффективной), а обработкой серьезных ошибок должен заниматься другой модуль. Высоконадежные системы состоят из модулей и многих уровней. Сообщения о серьезных ошибках, возникших на каждом уровне, передаются на следующий уровень, и в конце концов, возможно, человеку. Модуль, получивший сообщение о серьезной ошибке (которую не может исправить никакой другой модуль), может выполнить соответствующее действие, возможно, связанное с перезагрузкой ошибочного модуля или запуском менее сложного (но более надежного) резервного модуля. Выделить модуль в конкретной системе — задача проектирования, но в принципе модулем может быть класс, библиотека, программа или все программы в компьютере.

• Мониторинг подсистем в ситуациях, когда они не могут самостоятельно сообщить о проблеме. В многоуровневой системе за системами более низкого уровня следят системы более высоких уровней. Многие системы, сбой которых недопустим (например, судовые двигатели или контроллеры космической станции), имеют по три резервные копии критических подсистем. Такое утроение означает не просто наличие двух резервных копий, но и то, что решение о том, какая из подсистем вышла из строя, решается голосованием “два против одного”. Утроение особенно полезно, когда многоуровневая организация представляет собой слишком сложную задачу (например, когда самый высокий уровень системы или подсистемы никогда не должен выходить из строя).

Мы можем спроектировать систему так, как хотели, и реализовать ее так, как умели, и все равно она может оставаться неисправной. Прежде чем передавать пользователям, ее следует систематически и тщательно протестировать (подробнее об этом речь пойдет в главе 26).

25.3. Управление памятью

Двумя основными ресурсами компьютера являются время (на выполнение инструкций) и память (для хранения данных и кода). В языке С++ есть три способа выделения памяти для хранения данных (см. разделы 17.4 и A.4.2).

• Статическая память. Выделяется редактором связей и существует, пока выполняется программа.

• Стековая (автоматическая) память. Выделяется при вызове функции и освобождается после возвращения управления из функции.

• Динамическая память (куча). Выделяется оператором

new

и освобождается для возможного повторного использования с помощью оператора

delete

.

Рассмотрим каждую из них с точки зрения программирования встроенных систем. В частности, изучим вопросы управления памятью с точки зрения задач, где важную роль играет предсказуемость (см. раздел 25.2.1), например, при программировании систем с жесткими условиями реального времени и систем с особыми требованиями к обеспечению безопасности.

Статическая память не порождает особых проблем при программировании встроенных систем: вся память тщательно распределяется еще до старта программы и задолго до развертывания системы.

Стековая память может вызывать проблемы, поскольку ее может оказаться недостаточно, но эту проблему устранить несложно. Разработчики системы должны сделать так, чтобы в ходе выполнения программы стек никогда не превышал допустимый предел. Как правило, это означает, что количество вложенных вызовов функций должно быть ограниченным; иначе говоря, мы должны иметь возможность показать, что цепочки вызовов (например,

f1

вызывает

f2

вызывает ... вызывает

fn

) никогда не станут слишком длинными. В некоторых системах это приводит к запрету на рекурсивные вызовы. В некоторых системах такие запреты в отношении некоторых рекурсивных функций являются вполне оправданными, но их нельзя считать универсальными. Например, я знаю, что вызов инструкция

factorial(10)

вызовет функцию

factorial

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

factorial

(см. раздел 15.5), чтобы избежать сомнений или случайностей.

Динамическое распределение памяти обычно запрещено или строго ограничено; иначе говоря, оператор new либо запрещен, либо его использование ограничено периодом запуска программы, а оператор

delete

запрещен. Укажем основные причины этих ограничений.

• Предсказуемость. Размещение данных в свободной памяти непредсказуемо; иначе говоря, нет гарантии, что эта операция будет выполняться за постоянное время. Как правило, это не так: во многих реализациях оператора

new

время, необходимое для размещения нового объекта, может резко возрастать после размещения и удаления многих объектов.

• Фрагментация. Свободная память может быть фрагментированной; другими словами, после размещения и удаления объектов оставшаяся память может содержать большое количество “дыр”, представляющих собой неиспользуемую память, которая бесполезна, потому что каждая “дыра” слишком мала для того, чтобы в ней поместился хотя бы один объект, используемый в приложении. Таким образом, размер полезной свободной памяти может оказаться намного меньше разности между первоначальным размером и размером размещенных объектов.