7.1. Отделение контроля сложности от настройки производительности
7.1. Отделение контроля сложности от настройки производительности
Прежде всего, необходимо избавиться от некоторых ложных целей. В данной главе обсуждение не касается использования одновременных операций для повышения производительности. Рассмотрение этой идеи до того как будет сформулирована ясная структура, которая сводит к минимуму глобальную сложность, является преждевременной оптимизацией, т.е. корнем всех зол (дальнейшее обсуждение приведено в главе 12).
Близкой ложной целью являются параллельные процессы (threads) (т.е. множество одновременно выполняемых процессов, совместно использующих одно адресное пространство памяти). Использование параллельных процессов — средство повышения производительности. Для того чтобы не уходить далеко от основной линии обсуждения, данная методика более подробно рассматривается в конце данной главы. Здесь достаточно сделать обобщение: параллельные процессы не уменьшают глобальную сложность, а скорее увеличивают ее, и поэтому следует избегать их использования, кроме случаев крайней необходимости.
С другой стороны, соблюдение правила модульности не является ложной целью, поскольку модульность позволяет упростить программы и, следовательно, работу программиста. Все причины для разделения процессов являются продолжением причин для разделения модулей, которое рассматривалось в главе 4.
Другой важной причиной разбиения программ на взаимодействующие процессы является повышение безопасности. В операционной системе Unix программы, которые запускаются обычными пользователями, но должны иметь доступ к важным с точки зрения безопасности системным ресурсам, получают такой доступ с помощью функции setuicf. Исполняемые файлы представляют собой наименьший элемент кода, который может содержать setuid-бит. Следовательно, каждая строка кода в исполняемом setuid-файле должна быть "благонадежной". (Вместе с тем хорошо написанные setuid-программы, сначала предпринимают все необходимые привилегированные действия, а на последующих этапах своей работы понижают свои привилегии до уровня пользователя.)
Обычно привилегии setuid-программы требуются для выполнения ею одной или нескольких операций. Часто имеется возможность разбить такую программу на взаимодействующие процессы: мелкий, не требующий использования функции setuid, и более крупный, который в ней не нуждается. Если такое разделение возможно, то "благонадежным" должен быть только код в меньшей программе. В значительной степени благодаря подобному разделению и делегированию функций, операционная система Unix обладает большими достижениями в обеспечении безопасности48, чем ее конкуренты.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
1.9 Сложности практической реализации
1.9 Сложности практической реализации Стек ввода-вывода подсистемы хранения в семействе Windows Server описан в этой главе довольно подробно. Но помните, что стек подсистемы хранения не обслуживает устройства, поддерживающие несколько протоколов.Чтобы повысить надежность и
2.7 Сложности практической реализации
2.7 Сложности практической реализации В новой модели драйверов Storport оптимизированы функции ввода-вы- вода и общая производительность системы управления. Однако системный администратор и менеджеры по закупкам в информационных отделах компаний должны знать, что новая
3.8 Сложности практической реализации
3.8 Сложности практической реализации Начиная с Windows 2000, компания Microsoft предоставляет новую модель мини-драйвера, которая позволяет независимым поставщикам создавать сетевые файловые системы. От поставщиков требуется создать мини-драйвер, который поддерживает
6.7 Сложности практической реализации
6.7 Сложности практической реализации В Windows 2000 впервые появилась поддержка динамических дисков. Следует обратить внимание на процесс улучшения поддержки динамических дисков компанией Microsoft, что понадобится при установке системы и предустановке дисков независимыми
7.10 Сложности практической реализации
7.10 Сложности практической реализации Интересно наблюдать, как поддержка интерфейса WMI развивается от рекомендуемой до обязательной в наборах программной разработки Microsoft и в требованиях этой компании. Развитие WMI происходит согласно устоявшейся практике Microsoft, которая
8.3 Сложности практической реализации
8.3 Сложности практической реализации Администраторы и руководители отделов информационных технологий должны обратить внимание на то, ч; го поддержка протокола iSCSI не обеспечена в базовой версии Windows Server 2003. Таким образом, все системы на базе iSCSI, которые будут
9.5 Сложности практической реализации
9.5 Сложности практической реализации Использование массивов RAID является весьма привлекательным решением, поскольку позволяет избежать значительных потерь производительности и обеспечить отказоустойчивость. Было создано несколько схем массивов RAID, которые
Отделение интерфейса от реализации
Отделение интерфейса от реализации Концепция инкапсуляции основана на разделении того, как объект выглядит (его интерфейса), и того, как он в действительности работает (его реализации). Проблема в C++ в том, что этот принцип неприменим на двоичном уровне, так как класс C++
13.1.1. Три источника сложности
13.1.1. Три источника сложности Вопросы о простоте, сложности и верном размере программного обеспечения вызывают бурные споры в Unix-сообществе. Unix-программисты развили такое мировоззрение, согласно которому простота — это красота, изящество и добро, а сложность — уродство,
7.1. Отделение контроля сложности от настройки производительности
7.1. Отделение контроля сложности от настройки производительности Прежде всего, необходимо избавиться от некоторых ложных целей. В данной главе обсуждение не касается использования одновременных операций для повышения производительности. Рассмотрение этой идеи до того
13.1.1. Три источника сложности
13.1.1. Три источника сложности Вопросы о простоте, сложности и верном размере программного обеспечения вызывают бурные споры в Unix-сообществе. Unix-программисты развили такое мировоззрение, согласно которому простота — это красота, изящество и добро, а сложность — уродство,
13.1.4. Диаграмма видов сложности
13.1.4. Диаграмма видов сложности Выше были показаны две различные шкалы для анализа сложности. Данные шкалы фактически перпендикулярны друг другу. Рис. 13.1 может помочь при выяснении связей. В каждом из девяти блоков на рисунке приведен общий источник определенного вида
13.3.1. Идентификация проблем сложности
13.3.1. Идентификация проблем сложности В каждом текстовом редакторе присутствует определенный уровень необходимой сложности. Как минимум, редактор должен поддерживать во внутреннем буфере копию файла или файлов, редактируемых пользователем в текущий момент.
Пример повышенной сложности
Пример повышенной сложности Вот более сложный пример применения разных аспектов дублируемого наследования.Проблема, близкая по духу нашему примеру, возникла из интересного обсуждения в основной книге по C++ [Stroustrup 1991].Рассмотрим класс WINDOW с процедурой display и двумя
ПИСЬМОНОСЕЦ: Шкаф, правое отделение, 2-я полка сверху, за ползунками
ПИСЬМОНОСЕЦ: Шкаф, правое отделение, 2-я полка сверху, за ползунками Автор: Илья Щуров VoyagerУважаемая «Компьютерра»! Родилась недавно у меня одна идея, подстегнутая попытками не пропустить очередной номер любимого журнала в киоске. Киоскерши постоянно меняются, со всеми не