Файл: Учебнометодическое пособие Томск 2016 2 удк 004. 451(075. 8) Ббк 32. 973. 2018. 2я73 к 754 Рецензенты.pdf

111
Любой информационный канал позволяет подключенным к нему процес- сам использовать два системных вызова:
ЧТЕНИЕ_ИНФ.КАНАЛА (…||…), ЗАПИСЬ_ИНФ.КАНАЛ (…||…).
При этом каждый информационный канал обладает характеристиками, отражающими его пригодность для передачи данных между процессами. Неко- торые из этих характеристик:
1) направление передачи данных. Информационные каналы делятся на симплексные, полудуплексные и дуплексные. Симплексный канал позволяет передавать данные только в одном направлении, полудуп-
лексные – в обоих направлениях неодновременно, а дуплексный – в обоих направлениях одновременно;
2) структурированность передаваемых данных. Различают информаци- онные каналы, передающие потоки данных и передающие сообщения;
3) поток данных – последовательность байтов, в состав которой не вхо- дят какие-то особые байты, используемые информационным каналом;
4) сообщение – последовательность байтов, предваряемая специальными служебными байтами;
5) устойчивость информационного канала. Будем различать виртуаль-
ные соединения – устойчивые каналы, предназначенные для передачи потока данных или для передачи последовательности сообщений, а также датаграммные каналы, предназначенные для передачи от- дельных, не связанных между собой сообщений, называемых дата-
граммами;
6) параллельность передаваемых данных. Будем различать моноканалы и мультиплексные каналы. В любой момент временимоноканалсо- держит по каждому из двух направлений передачи только однотипные передаваемые данные. Мультиплексный канал выполняет на своем передающем конце (концах) мультиплексирование – объединение данных, передаваемых от нескольких источников. На приемном конце
(концах) такой канал выполняетдемультиплексирование – разделение переданных данных между несколькими приемниками.
В качестве примера рассмотрим одно из средств межпроцессного инфор- мационного взаимодействия – каналы. Наглядно канал можно представить в виде трубы, в которую с одной стороны один или несколько процессов направляют (записывают) последовательности байтов, а с другой – один или

112 несколько процессов выбирают (считывают) последовательности байтов. Ос- новные свойства канала:
1) последовательность байтов, помещаемых в канал одним процессом за одну операцию записи, не может быть перемешана с какой-то после- довательностью байтов от другого процесса;
2) длины считываемых из канала последовательностей байтов никак не зависят от длин записываемых последовательностей байтов.
Более точное определение:
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Канал – специальный файл, запись в который возможна
только с одного, а чтение – с другого конца.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Причем операции различных процессов с этим файлом синхронизирова- ны. Существуют два типа каналов – обыкновенные и именованные.
Обыкновенный каналсоздается в результате системного вызова:
СОЗДАТЬ_КАНАЛ (|| i
1
, i
2
), (на Си – pipe),
где i
1
– программное имя (номер) файла, открытого для записи в канал; i
2
– номер файла, открытого для чтения из канала.
Таким образом, один и тот же файл-канал оказывается открыт дважды и поэтому имеет два номера. Теперь процесс, выдавший данный вызов, может записывать в канал и считывать из него, пользуясь обычными системными вы- зовами для работы с файлами:
ЧТЕНИЕ_ФАЙЛА (i
2,
A
b
, n b
||), (на Си – read),
ЗАПИСЬ_ФАЙЛ (i
1,
A
b
, n b
||), (на Си – write), где A
b
– начальный адрес области ОП, в которую производится чтение из фай- ла-канала или из которой производится запись в канал; n
b
– число читаемых (записываемых) байтов.
Конечно, процесс создает канал не для того, чтобы посылать данные са- мому себе. Напомним, что в однопрограммной системе номера открытых фай- лов наследуются дочерними программами. В мультипрограммной системе это полезное свойство полностью сохраняется. Поэтому процесс, создавший канал, может использовать его для информационного обмена как с дочерними процес- сами, так и с более «младшими» потомками. Во избежание путаницы рекомен- дуется, чтобы в каждой программе, использующей канал, этот канал должен быть открыт только один раз – или на чтение, или на запись. Поэтому второй

113 файл следует закрыть. В результате канал становится симплексным. Другие свойства этого канала следуют из записанных ранее системных вызовов чтения и записи: устойчивый моноканал для передачи потока данных.
Операция чтения из канала может завершиться одним из следующих ва- риантов:
1) при чтении меньшего числа байтов, чем находится в канале, операция завершается успешно;
2) при чтении большего числа байтов, чем находится в канале, считыва- ется имеющееся число байтов. Процесс сам должен обработать ситуа- цию, когда получено меньше, чем заказано;
3) если канал пуст, и он не открыт на запись ни в одном из процессов, то в результате чтения из канала выдается 0 байтов. Если же канал открыт на запись хотя бы в одном процессе, системный вызов чтения будет забло- кирован до появления в канале данных.
Операция записи в канал может завершиться одним из следующих вари- антов:
1) при записи меньшего числа байтов, чем имеется свободного места в канале, операция завершается успешно;
2) при записи в канал большего числа байтов, чем имеется в нем свобод- ного места, вызовЗАПИСЬ_ФАЙЛ блокируется до освобождения тре- буемого места;
3) если процесс пытается выполнить запись в канал, не открытый ни од- ним процессом на чтение, то в этот процесс посылается сигнал
SIGPIPE
. По умолчанию сигнал SIGPIPE завершает процесс.
Существенным недостатком обыкновенных каналов является то, что они могут использоваться для информационного взаимодействия только между родственными процессами. Для неродственных процессов номера открытых файлов не могут использоваться в качестве идентификаторов совместно ис- пользуемых каналов. Другим существенным недостатком обыкновенных кана- лов является то, что они существуют недолго, лишь во время существования использующих их процессов.
Несмотря на перечисленные недостатки, обыкновенные каналы относятся к самым используемым средствам информационного взаимодействия между процессами. В частности, такими каналами соединяются все процессы, коман- ды запуска которых образуют конвейер, набираемый пользователем в команд-

114 ной строке shell (см. пп. 2.5.3). В данном случае каналы создает shell, до- черними процессами которого и являются процессы, образующие конвейер.
Если требуется обеспечить обмен информацией между «не родственны- ми» процессами, то для этого можно использовать именованные каналы, кото- рые реализованы не во всех UNIX-системах. Именованный канал имеет имя, аналогичное имени обычного файла. Это имя канал получает при своем созда- нии в результате выполнения процессом системного вызова:
СОЗДАТЬ_ИМЕННОЙ_КАНАЛ (I, m ||), (на Си – mkfifo),
где I – символьное имя файла-канала; m– права доступа к каналу (рассматриваются в п. 4.2).
После создания канала он может быть открыт на чтение или на запись в любом числе процессов с помощью вызова:
ОТКРЫТЬ_ФАЙЛ (I, r || i), (на Си – open), где r – режим работы процесса с файлом-каналом (чтение и (или) запись); i – программное имя (номер) файла, уникальное для данного процесса.
Процесс, открывший канал, может использовать далее вызовы чтения и записи точно так же, как и при работе с обыкновенным каналом.
В отличие от обыкновенных каналов именованные каналы «видны» для пользователя. С помощью команды shell – mknod он может создавать новые именованные каналы, чтобы затем использовать их для связи между процесса- ми. Для того чтобы затем подсоединить канал к процессу, достаточно перена- править стандартный ввод (вывод) процесса на этот файл-канал.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Контрольные вопросы по главе 3
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
1. Какие аппаратные и программные ресурсы используются процессами реально параллельно?
2. Какие ресурсы присущи как мультипрограммной, так и однопро- граммной операционной системе?
3. Какие программы и подпрограммы возможно выполнять в двух режи- мах ЦП – привилегированном и непривилегированном?
4. В чем отличие процессов-демонов от процессов-зомби?

115
4 Поддержка многопользовательской работы
и структура системы
4.1 Управление доступом пользователя в систему
Поддержка (то есть обеспечение) многопользовательской работы системы выполняется, в основном, на программном уровне, то есть самой ОС. Для этого в рамках мультипрограммной системы выполняются дополнительные систем- ные программы, обеспечивающие такую поддержку. Наиболее общая задача по обеспечению многопользовательской работы заключается в том, чтобы огра- дить работу в системе каждого конкретного пользователя от воздействий со стороны других пользователей.
Многие однопользовательские системы, например современные Windows, предусматривают работу многих пользователей, но не в параллельном, а в по- следовательном режиме. Поддержка последовательной работы пользователей предусматривает реализацию некоторых проектных решений, полученных при разработке многопользовательских систем, наиболее ярким представителем ко- торых является система UNIX.
Как воспринимает своего пользователя ОС? Будучи «бюрократом», любая
ОС рассматривает пользователя не учитывая его многочисленные достоинства и недостатки, а исходя из нескольких формальных показателей (атрибутов), за- регистрированных в системе. Первым из этих признаков, как всегда, является имя. Любой пользователь имеет два имени: символьное имя и номер, причем каждое из этих имен уникально в пределах всей системы. Символьное имя поль-
зователя предназначено для использования самими пользователями (при об- щении с ОС), а номер пользователя, как всегда, используется самой системой.
Например, обязательным пользователем в любой системе является суперпользо-
ватель, или администратор системы, имеющий в системе неограниченные права. Имена этого пользователя: root и 0.
Все пользователи системы делятся ее администратором на пересекающи- еся группы пользователей (не путать с группами процессов из пп. 3.4.2). За счет включения пользователя в группу он наделяется дополнительными правами, которыми обладают все члены группы. Каждая группа имеет два имени, уни- кальных по всей системе, – символьное имя группы и номер группы. Например, административная группа может иметь имена: root и 0. Имеющееся здесь

116 совпадение имен группы и пользователя вполне допустимо, так как каждое из имен должно быть уникально только в одной группе объектов (пользователи или группы). Каждый конкретный пользователь может быть одновременно членом одной, двух или большего числа групп. Группа пользователей, первая для данного пользователя, является для него первичной группой.
Еще один атрибут пользователя – пароль. Пароль представляет собой символьную строку (без пробелов) и используется ОС для идентификации пользователя в самом начале его сеанса с системой. Пароль выбирается самим пользователем с учетом требований, существующих в конкретной системе. Хо- роший пароль должен отвечать двум требованиям: 1) легко вспоминаться;
2) трудно подбираться. Рассмотрим теперь вопрос о том, где находится в си- стеме пароль пользователя и другие его атрибуты.
Любой модуль системы, аппаратный или программный, достойный вни- мания со стороны ОС, обязательно имеет блок управления. Блок управления, или дескриптор, – «паспорт» модуля, содержащий его атрибуты. При этом каждый блок управления может рассматриваться как структура данных, полями которой являются атрибуты модуля. Если в системе несколько однотипных мо- дулей, то их блоки управления объединяются в единую таблицу в качестве ее строк. Некоторые из блоков управления реализуются в виде не одной, а не- скольких структур данных, каждая из которых может являться строкой в одной из таблиц ОС. В данном пособии нам встретится много различных блоков управления.
Пользователи ВС, конечно, не являются ее модулями, но, представляя для
ОС значительный интерес, имеют свои блоки управления. Каждый такой блок представляет собой логическую запись в файле /etc/passwd, а весь этот файл может рассматриваться как таблица, содержащая сведения обо всех поль- зователях системы. Полями указанной логической записи являются:
1) символьное имя пользователя;
2) пароль пользователя в закодированном виде. Алгоритм кодирования пароля известен, но он не позволяет сделать обратный переход для получения самого пароля. В современных UNIX-системах с целью по- вышения безопасности данное поле содержит не пароль, который хранится в другом файле, а лишь символ «x» или «!»;
3) номер пользователя;
4) номер первичной группы пользователя;

117 5) комментарии, содержащие настоящее имя пользователя и, возможно, некоторые другие сведения о нем. Данное поле используется некото- рыми утилитами;
6) начальный каталог пользователя. Этот каталог является корнем под- дерева в файловой структуре системы, принадлежащего данному пользователю;
7) имя исполняемого файла программы, которую ОС запустит на выпол- нение в качестве первого ИК, обслуживающего данного пользователя.
Обычно это один из shell, но можно указать любую другую обраба- тывающую программу, не забывая о том, что завершение данной про- граммы означает завершение текущего сеанса работы пользователя в системе.
Файл /etc/passwdпо своей форме является обыкновенным текстовым файлом, доступным для чтения всем пользователям системы. Но вносить изме- нения в этот файл может только администратор. Только он может вносить из- менения и в текстовый файл /etc/group, содержащий перечень всех групп пользователей с указанием членов каждой группы.
Теперь рассмотрим порядок записи атрибутов пользователя во времени.
Во-первых, прежде чем пользователь начнет свой первый сеанс работы в си- стеме, администратор запишет его атрибуты, включая какой-то первоначаль- ный пароль, в файл /etc/passwd.
Во-вторых, сеанс работы пользователя в системе начинается с включения терминала. Согласно п. 3.2 после включения терминала системный процесс init порождает процесс shell, обслуживающий данного пользователя. Но это упрощенная схема. На самом деле init сначала порождает процесс getty
, ожидающий включения терминала. После этого включения программа процесса заменяется: вместо getty загружается программа login, которая запрашивает у пользователя имя и пароль. Если имя зарегистрировано в файле
/etc/passwd и пароль назван правильно, то login загружает вместо себя тот shell (или его заменитель), который указан в последнем поле записи фай- ла /etc/passwd, которая соответствует данному пользователю.
Таким образом, программа одного и того же процесса заменяется дважды на другую программу: gettyloginshell. Это не трудно обеспечить, так как любая программа может перекрыть себя другой программой, используя соответствующий системный вызов (рассматривается в п. 5.2). Кроме того, от-

118 метим, что login сравнивает не сами пароли, а их закодированные варианты.
В ходе своей работы в системе пользователь может заменить пароль, используя утилиту passwd.
Рассмотрим теперь, как осуществляет доступ в систему удаленный поль- зователь, соединенный с UNIX-системой не с помощью локального терминала, а с помощью линии связи или даже целой сети передачи данных [5].
Для обеспечения такого доступа изложенная выше схема должна быть скорректирована (рис. 4.1).
Рис. 4.1  Доступ удаленного пользователя в UNIX-систему
Удаленный пользователь запускает на своей локальной ЭВМ программу rlogin (клиент), которая с помощью своей ОС (не обязательно UNIX) посы- лает по сети в программу rlogin (сервер) запрос на вход в систему UNIX.
Процесс rlogin (сервер) является дочерним процессом процесса init, по- рождаемым им аналогично процессу getty, но предназначен для обслужива- ния не локальных, а удаленных запросов на вход в систему. Так как процессу

119 rlogin (сервер) терминал не нужен, то он создается процессом init как про- цесс-демон. После поступления каждого удаленного вызоваrlogin (сервер) создает очередной экземпляр заменителя терминала – псевдотерминал и по- рождает дочерний процесс login.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·