7 Мультипрограммирование: разделение процессов для разделения функций

7 Мультипрограммирование: разделение процессов для разделения функций

Если мы придаем большое значение структурам данных, то мы должны придавать большое значение независимой (и, следовательно, одновременной) обработке. Иначе для чего мы собираем объекты в структуру? Почему мы терпим языки, которые дают нам одно без другого?

Раздел Epigrams in Programming в журнале ACM SIGPLAN (17 #9, 1982) —Алан Перлис (Alan Perlis)

Наиболее характерной методикой разбиения программ на модули в операционной системе Unix является разделение крупных программ на множество взаимодействующих процессов. Обычно в мире Unix данная методика называется "многопроцессорной обработкой" (multiprocessing), но в этой книге, для того чтобы избежать путаницы с многопроцессорным аппаратным обеспечением, используется более ранний термин "мультипрограммирование" (multiprogramming).

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

В Unix-проектировании подход "решать одну задачу хорошо" применяется на уровне взаимодействующих программ подобно тому, как во взаимодействующих подпрограммах он применяется внутри программы. Особое значение придается мелким программам, соединенным четко определенным методом межпроцессного обмена данными или совместно используемыми файлами. Соответственно, операционная система Unix побуждает программистов разбивать создаваемые программы на более простые подпроцессы и уделять внимание интерфейсам между этими подпроцессами. Такой подход система обеспечивает тремя основными способами:

• малозатратное создание подпроцессов;

• предоставление методов, которые относительно упрощают обмен данными между процессами (вызовы с созданием подоболочки, перенаправление ввода/вывода, каналы, передача сообщений и сокеты);

• поддержка простых, прозрачных, текстовых форматов данных, которые могут передаваться посредством каналов и сокетов.

Малозатратное создание дочерних процессов и простое управление процессами являются весьма важными факторами для Unix-стиля программирования. В такой операционной системе, как VAX VMS, где запуск процессов является дорогой и медленной операцией, требующей специальных привилегий, программисты вынуждены создавать массивные монолиты,- поскольку не имеют другого выбора. К счастью, семейство Unix отличается направленностью в сторону более низких издержек fork(2), а не в сторону более высоких. В частности, операционная система Linux особенно эффективна в этом отношении, подпроцессы создаются в ней быстрее, чем возникают параллельные процессы во многих других операционных системах47.

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

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

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

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

Не сложно применить хороший стиль к синтаксису протокола прикладного уровня таких моделей, как SMTP, ВЕЕР или XML-RPC. Реальная сложность заключается не в синтаксисе протокола, а в его логике — проектировании протокола, который одновременно является достаточно выразительным и не имеет проблем взаимоблокировки процессов. Почти так же важно то, что протокол должен быть видимым, для того чтобы быть выразительным и свободным от взаимоблокировки. Программисты, пытающиеся мысленно моделировать поведение взаимодействующих программ и проверять его корректность, должны иметь возможность поступать именно так.

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Разделение тел

Из книги AutoCAD 2009 для студента. Самоучитель автора Соколова Татьяна Юрьевна

Разделение тел При разделении трехмерного тела команду редактирования SOLIDEDIT следует вызывать из падающего меню Modify ? Solid Editing ? Separate либо щелчком на пиктограмме Separate на плавающей панели инструментов Solid Editing. В команде используются ключи Body, Separate.При использовании команды


1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на


7 Мультипрограммирование: разделение процессов для разделения функций

Из книги Эффективное использование STL автора Мейерс Скотт

7 Мультипрограммирование: разделение процессов для разделения функций Если мы придаем большое значение структурам данных, то мы должны придавать большое значение независимой (и, следовательно, одновременной) обработке. Иначе для чего мы собираем объекты в структуру?


7.4. Разделение процессов на уровне проектирования

Из книги Основы AS/400 автора Солтис Фрэнк

7.4. Разделение процессов на уровне проектирования Рассмотрим конкретные рекомендации по использованию описанных выше методов.Прежде всего, необходимо отметить, что временные файлы, более интерактивный способ связи главного/подчиненного процессов, сокеты, RPC и все


11.6.8. Модель "разделения ядра и интерфейса"

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

11.6.8. Модель "разделения ядра и интерфейса" В главе 7 рассматривались доводы против создания крупных однопроцессных монолитов, а также обсуждалась возможность понижения глобальной сложности программ путем их разделения на взаимодействующие блоки. В мире Unix данная


Совет 46. Передавайте алгоритмам объекты функций вместо функций

Из книги Практика и проблематика моделирования бизнес-процессов автора Всяких Е И

Совет 46. Передавайте алгоритмам объекты функций вместо функций Часто говорят, что повышение уровня абстракции языков высокого уровня приводит к снижению эффективности сгенерированного кода. Александр Степанов, изобретатель STL, однажды разработал небольшой комплекс


Виртуальная память для систем разделения времени

Из книги C++. Сборник рецептов автора Диггинс Кристофер

Виртуальная память для систем разделения времени В связи с появлением в конце 60-х годов систем разделения времени — раннего этапа эволюции мультипрограммных ОС — многие производители компьютеров приняли виртуальную память на вооружение. При мультипрограммировании


1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей

Из книги AutoCAD 2009. Учебный курс автора Соколова Татьяна Юрьевна

1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на


7.4. Разделение процессов на уровне проектирования

Из книги AutoCAD 2008 для студента: популярный самоучитель автора Соколова Татьяна Юрьевна

7.4. Разделение процессов на уровне проектирования Рассмотрим конкретные рекомендации по использованию описанных выше методов.Прежде всего, необходимо отметить, что временные файлы, более интерактивный способ связи главного/подчиненного процессов, сокеты, RPC и все


11.6.8. Модель "разделения ядра и интерфейса"

Из книги Linux и UNIX: программирование в shell. Руководство разработчика. автора Тейнсли Дэвид

11.6.8. Модель "разделения ядра и интерфейса" В главе 7 рассматривались доводы против создания крупных однопроцессных монолитов, а также обсуждалась возможность понижения глобальной сложности программ путем их разделения на взаимодействующие блоки. В мире Unix данная


Разделение тел

Из книги автора

Разделение тел При разделении трехмерного тела команду редактирования SOLIDEDIT следует вызывать из падающего меню Modify ? Solid Editing ? Separate либо щелчком на пиктограмме Separate на плавающей панели инструментов Solid Editing. В команде используются ключи Body, Separate.При использовании команды


Разделение тел

Из книги автора

Разделение тел При разделении трехмерного тела команду редактирования SOLIDEDIT следует вызывать из падающего меню Modify ? Solid Editing ? Separate либо щелчком на пиктограмме Separate на плавающей панели инструментов Solid Editing. В команде используются ключи Body, Separate.При использовании команды


19.11.2. Вызов функций из файла функций

Из книги автора

19.11.2. Вызов функций из файла функций Мы уже рассматривали, каким образом функции вызываются из командной строки. Эти типы функций обычно используются утилитами, создающими системные сообщения.А теперь воспользуемся снова описанной выше функцией, но в этом случае


12.3.5. Адаптеры функций для объектов-функций

Из книги автора

12.3.5. Адаптеры функций для объектов-функций В стандартной библиотеке имеется также ряд адаптеров функций, предназначенных для специализации и расширения как унарных, так и бинарных объектов-функций. Адаптеры – это специальные классы, разбитые на следующие две