        ѓ‹Ђ‚Ђ 13. ђЂ‘Џђ…„…‹…ЌЌ›… ‘€‘’…Њ›


    ‚ предыдущей главе нами были рассмотрены сильносвЯзанные многопроцессор-
ные  системы  с общей памЯтью, общими структурами данных Ядра и общим пулом,
из которого процессы вызываютсЯ на выполнение. —асто, однако,  бывает  жела-
тельно  в  целЯх обеспечениЯ совместного использованиЯ ресурсов распределЯть
процессоры таким образом, чтобы они были автономны от операционной  среды  и
условий  эксплуатации.  Џусть, например, пользователю персональной ќ‚Њ нужно
обратитьсЯ к файлам, находЯщимсЯ на более крупной машине, но  сохранить  при
этом контроль над персональной ќ‚Њ. ЌесмотрЯ на то, что отдельные программы,
такие  как uucp, поддерживают передачу файлов по сети и другие сетевые функ-
ции, их использование не будет скрыто от пользователЯ,  поскольку  пользова-
тель  знает  о  том,  что он работает в сети. Љроме того, надо заметить, что
программы, подобные текстовым редакторам, с удаленными файлами, как с  обыч-
ными, не работают. Џользователи должны располагать стандартным набором функ-
ций  системы  UNIX  и,  за исключением возможной потери в быстродействии, не
должны ощущать пересечениЯ машинных границ. ’ак, например, работа  системных
функций  open  и read с файлами на удаленных машинах не должна отличатьсЯ от
их работы с файлами, принадлежащими локальным системам.
    Ђрхитектура распределенной системы представлена на ђисунке 13.1.  Љаждый
компьютер,  показанный на рисунке, ЯвлЯетсЯ автономным модулем, состоЯщим из
–Џ, памЯти и периферийных устройств. ‘оответствие модели не нарушаетсЯ  даже
несмотрЯ на то, что компьютер не располагает локальной файловой системой: он
должен  иметь  периферийные  устройства  длЯ свЯзи с другими машинами, а все
принадлежащие ему файлы могут располагатьсЯ и на ином компьютере. ”изическаЯ
памЯть, доступнаЯ каждой машине, не зависит  от  процессов,  выполнЯемых  на
других машинах. ќтой особенностью распределенные системы отличаютсЯ от силь-
носвЯзанных  многопроцессорных систем, рассмотренных в предыдущей главе. ‘о-
ответственно, и Ядро

+-----------------------------+    +-----------------------------+
|       +------------+        |    |       +------------+        |
|       | Џроцессоры |        |    |       | Џроцессоры |        |
|       +-----+------+        |    |       +-----+------+        |
| ----+-------+------+------- |    | ----+-------+------+------- |
| +---+----+ +-------+------+ |    | +---+----+ +-------+------+ |
| | ЏамЯть | | Џериферийные | |    | | ЏамЯть | | Џериферийные | |
| |        | |  устройства  | |    | |        | |  устройства  | |
| +--------+ +--------------+ +-++-+ +--------+ +--------------+ |
+-----------------------------+ ++ +-----------------------------+
                                |
                  +-------------+---------------+
                  |       +------------+        |
                  |       | Џроцессоры |        |
                  |       +-----+------+        |
                  | ----+-------+------+------- |
                  | +---+----+ +-------+------+ |
                  | | ЏамЯть | | Џериферийные | |
                  | |        | |  устройства  | |
                  | +--------+ +--------------+ |
                  +-----------------------------+

    ђисунок 13.1. Њодель системы с распределенной архитектурой

                                    381


системы на каждой машине функционирует независимо от внешних условий эксплу-
атации распределенной среды.
    ђаспределенные системы, хорошо описанные в литературе,  традиционно  де-
лЯтсЯ на следующие категории:
  *  периферийные  системы,  представлЯющие собой группы машин, отличающихсЯ
    Ярковыраженной общностью и свЯзанных с одной (обычно более крупной)  ма-
    шиной. Џериферийные процессоры делЯт свою нагрузку с центральным процес-
    сором  и переадресовывают ему все обращениЯ к операционной системе. –ель
    периферийной системы состоит в увеличении общей производительности  сети
    и  в  предоставлении  возможности выделениЯ процессора одному процессу в
    операционной среде UNIX. ‘истема запускаетсЯ как отдельный модуль; в от-
    личие от других моделей распределенных систем, периферийные  системы  не
    обладают  реальной  автономией, за исключением случаев, свЯзанных с дис-
    петчеризацией процессов и распределением локальной памЯти.
  * распределенные системы типа "Newcastle", позволЯющие  осуществлЯть  дис-
    танционную свЯзь по именам удаленных файлов в библиотеке (название взЯто
    из  статьи "The Newcastle Connection" - см. [Brownbridge 82]). “даленные
    файлы имеют спецификацию (составное имЯ), котораЯ в указании пути поиска
    содержит специальные символы или дополнительную компоненту имени,  пред-
    шествующую  корню файловой системы. ђеализациЯ этого метода не предпола-
    гает внесениЯ изменений в Ядро системы, вследствие этого он более прост,
    чем другие методы, рассматриваемые в этой главе, но менее гибок.
  * абсолютно "прозрачные" распределенные системы, в которых длЯ обращениЯ к
    файлам, расположенным на других машинах, достаточно указаниЯ их стандар-
    тных составных имен; распознавание этих файлов как  удаленных  входит  в
    обЯзанности  Ядра. Њаршруты поиска файлов, указанные в их составных име-
    нах, пересекают машинные границы в точках монтированиЯ, сколько бы таких
    точек ни было сформировано при монтировании файловых систем на дисках.

    ‚ настоЯщей главе мы рассмотрим архитектуру каждой модели; все  приводи-
мые сведениЯ базируютсЯ не на результатах конкретных разработок, а на инфор-
мации, публиковавшейсЯ в различных технических статьЯх. Џри этом предполага-
етсЯ, что забота об адресации, маршрутизации, управлении потоками, обнаруже-
нии и исправлении ошибок возлагаетсЯ на модули протоколов и драйверы устрой-
ств,  другими  словами,  что  каждаЯ модель не зависит от используемой сети.
Џримеры использованиЯ системных функций, приводимые в следующем разделе  длЯ
периферийных   систем,  работают  аналогичным  образом  и  длЯ  систем  типа
Newcastle и длЯ абсолютно "прозрачных" систем, о которых пойдет речь  позже;
поэтому  в деталЯх мы их рассмотрим один раз, а в разделах, посвЯщенных дру-
гим типам систем, остановимсЯ в основном на особенностЯх, отличающих эти мо-
дели от всех остальных.


        13.1 Џ…ђ€”…ђ€‰Ќ›… ЏђЋ–…‘‘Ћђ›

    Ђрхитектура периферийной системы показана на ђисунке  13.2.  –ель  такой
конфигурации состоит в повышении общей производительности сети за счет пере-
распределениЯ  выполнЯемых  процессов между центральным и периферийными про-
цессорами. “ каждого из периферийных процессоров нет в  распорЯжении  других
локальных  периферийных  устройств, кроме тех, которые ему нужны длЯ свЯзи с
центральным процессором. ”айловаЯ система и все устройства находЯтсЯ в  рас-
порЯжении  центрального  процессора.  Џредположим,  что все пользовательские
процессы исполнЯютсЯ на периферийном процессоре и между  периферийными  про-
цессорами не перемещаютсЯ; будучи однажды переданы процессору, они пребывают
на  нем  до  момента завершениЯ. Џериферийный процессор содержит облегченный
вариант операционной системы, предназначенный длЯ обработки локальных  обра-
щений к системе, управлениЯ прерываниЯми, распределениЯ памЯти, работы с се-
тевыми протоколами и с драйвером устройства свЯзи с центральным процессором.

                                    382

    Џри инициализации системы на центральном процессоре Ядро по линиЯм свЯзи
загружает  на каждом из периферийных процессоров локальную операционную сис-
тему. ‹юбой выполнЯемый на периферии процесс свЯзан  с  процессом-спутником,
принадлежащим  центральному  процессору  (см.  [Birrell 84]); когда процесс,
протекающий на периферийном процессоре, вызывает системную функцию,  котораЯ
нуждаетсЯ в услугах исключительно центрального процессора, периферийный про-
цесс свЯзываетсЯ со своим спутником и запрос поступает на обработку на цент-
ральный  процессор.  Џроцесс-спутник  исполнЯет системную функцию и посылает
результаты обратно на периферийный процессор. ‚заимоотношениЯ  периферийного
процесса  со своим спутником похожи на отношениЯ клиента и сервера, подробно
рассмотренные нами в главе 11: периферийный процесс выступает клиентом свое-
го спутника, поддерживающего функции работы с файловой  системой.  Џри  этом
удаленный процесс-сервер имеет только одного клиента. ‚ разделе 13.4 мы рас-
смотрим процессы-серверы, имеющие несколько клиентов.

    –ентральный процессор              Џериферийный процессор
+-----------------------------+    +-----------------------------+
|       +------------+        |    |       +------------+        |
|       | Џроцессоры |        |    |       | Џроцессоры |        |
|       +-----+------+        |    |       +-----+------+        |
| ----+-------+------+------- |    | ----+-------+-------------- |
| +---+----+ +-------+------+ |    | +---+----+                  |
| | ЏамЯть | | Џериферийные | |    | | ЏамЯть |                  |
| |        | |  устройства  | |    | |        |                  |
| +--------+ +--------------+ +-++-+ +--------+                  |
+-----------------------------+ ++ +-----------------------------+
                                |
                  +-------------+---------------+
                  |       +------------+        |
     Џериферийный |       | Џроцессоры |        |
     процессор    |       +-----+------+        |
                  | ----+-------+-------------- |
                  | +---+----+                  |
                  | | ЏамЯть |                  |
                  | |        |                  |
                  | +--------+                  |
                  +-----------------------------+

           ђисунок 13.2. ЉонфигурациЯ периферийной системы


    Љогда периферийный процесс вызывает системную функцию, которую можно об-
работать  локально,  Ядру  нет надобности посылать запрос процессу-спутнику.
’ак, например, в целЯх получениЯ дополнительной памЯти процесс может вызвать
длЯ локального исполнениЯ функцию sbrk. Ћднако, если требуютсЯ услуги  цент-
рального  процессора, например, чтобы открыть файл, Ядро кодирует информацию
о передаваемых вызванной функции параметрах и условиЯх выполнениЯ процесса в
некое сообщение,  посылаемое  процессу-спутнику  (ђисунок  13.3).  ‘ообщение
включает в себЯ признак, из которого следует, что системнаЯ функциЯ выполнЯ-
етсЯ  процессом-спутником от имени клиента, передаваемые функции параметры и
данные о среде выполнениЯ процесса (например, пользовательский  и  групповой
коды  идентификации),  которые длЯ разных функций различны. ЋставшаЯсЯ часть
сообщениЯ представлЯет собой данные переменной  длины  (например,  составное
имЯ файла или данные, предназначенные длЯ записи функцией write).
    Џроцесс-спутник ждет поступлениЯ запросов от периферийного процесса; при
получении запроса он декодирует сообщение, определЯет тип системной функции,
исполнЯет ее и преобразует результаты в ответ, посылаемый периферийному про-
цессу.  Ћтвет,  помимо  результатов выполнениЯ системной функции, включает в
себЯ сообщение об

                                    383

”ормат сообщениЯ
+----------------+----------+---------------+--------------------+
| Џризнак вызова |Џараметры |„анные о среде |    ‘оставное имЯ   |
| системной функ-|системной |выполнениЯ про-|-------  или  ------|
| ции            |функции   |цесса          |    поток данных    |
+----------------+----------+---------------+--------------------+

    Ћтвет
    +------------+-----------+---------+---------------------+
    | ђезультаты | ‘ообщение | Ќомер   |                     |
    | выполнениЯ | об ошибке | сигнала |---- Џоток данных ---|
    | системной  |           |         |                     |
    | функции    |           |         |                     |
    +------------+-----------+---------+---------------------+

                 ђисунок 13.3. ”орматы сообщений


ошибке (если она имела место), номер сигнала и массив данных переменной дли-
ны, содержащий, например, информацию,  прочитанную  из  файла.  Џериферийный
процесс приостанавливаетсЯ до получениЯ ответа, получив его, производит рас-
шифровку  и  передает  результаты пользователю. ’акова общаЯ схема обработки
обращений к операционной системе; теперь перейдем к более  детальному  расс-
мотрению отдельных функций.
    „лЯ  того, чтобы объЯснить, каким образом работает периферийнаЯ система,
рассмотрим рЯд функций: getppid, open, write, fork, exit и  signal.  ”ункциЯ
getppid  довольно проста, поскольку она свЯзана с простыми формами запроса и
ответа, которыми обмениваютсЯ периферийный и центральный процессоры. џдро на
периферийном процессоре формирует сообщение, имеющее  признак,  из  которого
следует,  что  запрашиваемой  функцией  ЯвлЯетсЯ функциЯ getppid, и посылает
запрос центральному процессору. Џроцесс-спутник  на  центральном  процессоре
читает  сообщение  с  периферийного процессора, расшифровывает тип системной
функции, исполнЯет ее и получает идентификатор  своего  родителЯ.  ‡атем  он
формирует ответ и передает его периферийному процессу, находЯщемусЯ в состо-
Янии  ожиданиЯ на другом конце линии свЯзи. Љогда периферийный процессор по-
лучает  ответ,  он  передает  его  процессу,  вызвавшему  системную  функцию
getppid.  …сли же периферийный процесс хранит данные (такие, как идентифика-
тор процесса-родителЯ) в локальной памЯти, ему вообще не придетсЯ свЯзывать-
сЯ со своим спутником.
    …сли производитсЯ обращение к системной функции open, периферийный  про-
цесс  посылает  своему  спутнику соответствующее сообщение, которое включает
имЯ файла и другие параметры. ‚ случае успеха процесс-спутник  выделЯет  ин-
декс  и точку входа в таблицу файлов, отводит запись в таблице пользователь-
ских дескрипторов файла в своем пространстве и возвращает  дескриптор  файла
периферийному процессу. ‚се это времЯ на другом конце линии свЯзи периферий-
ный процесс ждет ответа. “ него в распорЯжении нет никаких структур, которые
хранили бы информацию об открываемом файле; возвращаемый функцией open деск-
риптор  представлЯет  собой  указатель  на запись в таблице пользовательских
дескрипторов файла, принадлежащей процессу-спутнику.  ђезультаты  выполнениЯ
функции показаны на ђисунке 13.4.
    …сли производитсЯ обращение к системной функции write, периферийный про-
цессор формирует сообщение, состоЯщее из признака функции write, дескриптора
файла и объема записываемых данных. ‡атем из пространства периферийного про-
цесса  он  по линии свЯзи копирует данные процессу-спутнику. Џроцесс-спутник
расшифровывает полученное сообщение, читает данные из линии свЯзи и  записы-
вает  их  в  соответствующий файл (в качестве указателЯ на индекс которого и
запись о котором в таблице файлов используетсЯ содержащийсЯ в сообщении дес-
криптор); все указанные действиЯ выполнЯютсЯ на центральном  процессоре.  Џо


                                    384

         –ентральный процессор             Џериферийный процессор
+--------------------------------------+   +---------------------+
|                    таблица           |   |                     |
|                    пользо-           |   |                     |
|                    ватель-           |   |                     |
|                    ских              |   |                     |
|                    дескрип-          |   |                     |
| таблица   таблица  торов             |   |                     |
| индексов  файлов   файла   +--------+|   |     +---------+     |
| +-----+   +-----+  +-----+ |Џроцесс-|----------| Џроцесс |     |
| |     |   |     |  |     | |спутник ||   |     +---------+     |
| +-----+   +-----+  +-----+ +-+------+|   |                     |
| |    -+-+ |     | ++-   -+---+       |   |                     |
| +-----+ | +-----+ |+-----+ дескрип-  |   |                     |
| |     | +-+-   -+-+|     | тор файла |   |                     |
| +-----+   +-----+  +-----+           |   |                     |
| |     |   |     |                    |   |                     |
| +-----+   +-----+                    |   |                     |
| |     |   |     |                    |   |                     |
| +-----+   +-----+                    |   |                     |
+--------------------------------------+   +---------------------+

    ђисунок 13.4. ‚ызов функции open из периферийного процесса


окончании  работы  процесс-спутник  передает периферийному процессу посылку,
подтверждающую прием сообщениЯ и содержащую количество байт данных,  успешно
переписанных  в файл. ЋперациЯ read выполнЯетсЯ аналогично; спутник информи-
рует периферийный процесс о количестве реально прочитанных  байт  (в  случае
чтениЯ данных с терминала или из канала это количество не всегда совпадает с
количеством, указанным в запросе). „лЯ выполнениЯ как той, так и другой фун-
кции  может потребоватьсЯ многократнаЯ пересылка информационных сообщений по
сети, что определЯетсЯ объемом пересылаемых данных и размерами сетевых паке-
тов.
    …динственной функцией, требующей внесениЯ изменений при работе на  цент-
ральном процессоре, ЯвлЯетсЯ системнаЯ функциЯ fork. Љогда процесс исполнЯет
эту  функцию на –Џ, Ядро выбирает длЯ него периферийный процессор и посылает
сообщение специальному процессу -серверу, информируЯ последний  о  том,  что
собираетсЯ  приступить к выгрузке текущего процесса. ЏредполагаЯ, что сервер
принЯл запрос, Ядро с помощью функции fork создает новый  периферийный  про-
цесс,  выделЯЯ запись в таблице процессов и адресное пространство. –ентраль-
ный процессор выгружает копию процесса, вызвавшего функцию fork, на  перифе-
рийный  процессор,  затираЯ только что выделенное адресное пространство, по-
рождает локальный спутник длЯ свЯзи с новым периферийным процессом и посыла-
ет на периферию сообщение о необходимости инициализации счетчика команд  длЯ
нового процесса. Џроцесс-спутник (на –Џ) ЯвлЯетсЯ потомком процесса, вызвав-
шего функцию fork; периферийный процесс с технической точки зрениЯ выступает
потомком  процесса-сервера, но по логике он ЯвлЯетсЯ потомком процесса, выз-
вавшего функцию fork. Џроцесс-сервер не имеет логической свЯзи с потомком по
завершении функции fork; единственнаЯ задача сервера состоит в оказании  по-
мощи  при  выгрузке  потомка. €з-за сильной свЯзи между компонентами системы
(периферийные процессоры не располагают автономией) периферийный  процесс  и
процесс-спутник  имеют  один  и  тот же код идентификации. ‚заимосвЯзь между
процессами показана на ђисунке 13.5: непрерывной линией показана свЯзь  типа
"родитель-потомок", пунктиром - свЯзь между равноправными партнерами.
    Љогда  процесс исполнЯет функцию fork на периферийном процессоре, он по-
сылает сообщение своему спутнику на –Џ, который и исполнЯет после этого  всю
вышеописанную последовательность действий. ‘путник выбирает новый периферий-


                                    385

     –ентральный процессор            Џериферийный процессор
    +----------------------+         +----------------------+
    | +------------------+ |         | +------------------+ |
    | | Џроцесс-родитель |-------------|  Џроцесс-сервер  | |
    | +---------+--------+ |         | +------------------+ |
    |           |          |         |                      |
    |           |          |         |                      |
    | +---------+--------+ |         | +------------------+ |
    | | Џорожденный спут-|-------------| Џорожденный про- | |
    | |        ник       | |         | |       цесс       | |
    | +------------------+ |         | +------------------+ |
    +----------------------+         +----------------------+

    ђисунок 13.5. ‚ыполнение функции fork на центральном процессоре


ный  процессор  и делает необходимые приготовлениЯ к выгрузке образа старого
процесса: посылает периферийному процессу-родителю запрос на чтение его  об-
раза,  в  ответ  на который на другом конце канала свЯзи начинаетсЯ передача
запрашиваемых данных. ‘путник считывает передаваемый  образ  и  переписывает
его   периферийному  потомку.  Љогда  выгрузка  образа  заканчиваетсЯ,  про-
цесс-спутник исполнЯет функцию fork, создаваЯ своего потомка на –Џ, и  пере-
дает значение счетчика команд периферийному потомку, чтобы последний знал, с
какого  адреса начинать выполнение. Ћчевидно, было бы лучше, если бы потомок
процесса-спутника назначалсЯ периферийному потомку в качестве родителЯ,  од-
нако  в нашем случае порожденные процессы получают возможность выполнЯтьсЯ и
на других периферийных процессорах, а не только на том, на котором они  соз-
даны.  ‚заимосвЯзь  между  процессами по завершении функции fork показана на
ђисунке 13.6. Љогда периферийный процесс завершает свою работу, он  посылает
соответствующее  сообщение процессу-спутнику и тот тоже завершаетсЯ. Ћт про-
цесса-спутника инициатива завершениЯ работы исходить не может.

                       –ентральный процессор
    +-------------------------------------------------------+
    |   +------------------+          +-----------------+   |
    |   | ‘путник-родитель +----------+ ‘путник-потомок |   |
    |   +------------------+          +-----------------+   |
    |             -                            -            |
    +-------------------------------------------------------+
                -                                -
+---------------------------+        +---------------------------+
|             -             |        |             -             |
| +-----------------------+ |        | +----------------------+  |
| | Џериферийный родитель | |        | | Џериферийный потомок |  |
| +-----------------------+ |        | +----------------------+  |
+---------------------------+        +---------------------------+
    Џериферийный процессор               Џериферийный процессор

    ђисунок 13.6. ‚ыполнение функции fork на периферийном процессоре


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

                                    386

полнение функции аварийно,  процессу-спутнику  в  многопроцессорной  системе
следует вести себЯ тем же образом. ’о же самое можно сказать и о том случае,
когда  сигнал  побуждает процесс к завершению своей работы с помощью функции
exit: периферийный процесс завершаетсЯ и посылает соответствующее  сообщение
процессу-спутнику, который, разумеетсЯ, тоже завершаетсЯ.
    Љогда  периферийный процесс вызывает системную функцию signal, он сохра-
нЯет текущую информацию в локальных таблицах  и  посылает  сообщение  своему
спутнику, информируЯ его о том, следует ли указанный сигнал принимать или же
игнорировать.  Џроцессу-спутнику  безразлично, выполнЯть ли перехват сигнала
или действие по умолчанию. ђеакциЯ процесса на сигнал зависит от трех факто-
ров (ђисунок 13.7): поступает ли сигнал во времЯ выполнениЯ  процессом  сис-
темной  функции, сделано ли с помощью функции signal указание об игнорирова-
нии сигнала, возникает ли сигнал на этом же периферийном процессоре  или  на

    +------------------------------------------------------------+
    | алгоритм sighandle    /* алгоритм обработки сигналов */    |
    | входнаЯ информациЯ:  отсутствует                           |
    | выходнаЯ информациЯ: отсутствует                           |
    | {                                                          |
    |    если (текущий процесс ЯвлЯетсЯ чьим-то спутником или    |
    |     имеет прототипа)                                       |
    |    {                                                       |
    |       если (сигнал игнорируетсЯ)                           |
    |           вернуть управление;                              |
    |       если (сигнал поступил во времЯ выполнениЯ системной  |
    |        функции)                                            |
    |           поставить сигнал перед процессом-спутником;      |
    |       в противном случае                                   |
    |           послать сообщение о сигнале периферийному процес-|
    |            су;                                             |
    |    }                                                       |
    |    в противном случае       /* периферийный процесс */     |
    |    {                                                       |
    |       /* поступил ли сигнал во времЯ выполнениЯ системной  |
    |        * функции или нет                                   |
    |        */                                                  |
    |       послать сигнал процессу-спутнику;                    |
    |    }                                                       |
    | }                                                          |
    |                                                            |
    | алгоритм satellite_end_of_syscall    /* завершение систем- |
    |                                       * ной функции, выз-  |
    |                                       * ванной периферийным|
    |                                       * процессом */       |
    | входнаЯ информациЯ:  отсутствует                           |
    | выходнаЯ информациЯ: отсутствует                           |
    | {                                                          |
    |    если (во времЯ выполнениЯ системной функции поступило   |
    |     прерывание)                                            |
    |       послать периферийному процессу сообщение о прерыва-  |
    |        нии, сигнал;                                        |
    |    в противном случае    /* выполнение системной функции не|
    |                           * прерывалось */                 |
    |       послать ответ: включить флаг, показывающий поступле- |
    |        ние сигнала;                                        |
    | }                                                          |
    +------------------------------------------------------------+

       ђисунок 13.7. Ћбработка сигналов в периферийной системе

                                    387


каком-то другом. Џерейдем к рассмотрению различных возможностей.
    „опустим, что периферийный процесс приостановил свою работу на то времЯ,
пока  процесс-спутник  исполнЯет системную функцию от его имени. …сли сигнал
возникает в другом месте, процесс-спутник обнаруживает его раньше, чем пери-
ферийный процесс. ‚озможны три случаЯ.
 1. …сли в ожидании некоторого событиЯ процесс-спутник не переходил в состо-
    Яние приостанова, из которого он вышел бы по получении сигнала,  он  вы-
    полнЯет системную функцию до конца, посылает результаты выполнениЯ пери-
    ферийному процессу и показывает, какой из сигналов им был получен.
 2.  …сли  процесс  сделал  указание  об игнорировании сигнала данного типа,
    спутник продолжает следовать алгоритму выполнениЯ системной функции,  не
    выходЯ из состоЯниЯ приостанова по longjmp. ‚ ответе, посылаемом перифе-
    рийному процессу, сообщение о получении сигнала будет отсутствовать.
 3. …сли по получении сигнала процесс-спутник прерывает выполнение системной
    функции  (по longjmp), он информирует об этом периферийный процесс и со-
    общает ему номер сигнала.

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


             Џериферийный процесс             Џроцесс-спутник
    +------------------------------------------------------------
    |    ‚ызывает системную функцию read              -
    |   Џосылает сообщение о вызове функции           -
    |          процессу-спутнику                      -
    |    ЏриостанавливаетсЯ до получениЯ              -
    |      ответа от процесса-спутника       Џолучает сообщение о
    |                   -                   вызове системной функ-
    |                   -                         ции read
    |                   -                    —итает данные с тер-
    |                   -                          минала
    |                   -                    ЏриостанавливаетсЯ в
    |                   -                     ожидании получениЯ
    |                   -                       порции данных
    |                   -                             -
    |                   -                             -
    |                   -                    ‘игнал (пользователь
    |                   -                   нажал клавишу "break")
    |                   -                    ‚ыходит из состоЯниЯ
    |                   -                         приостанова
    |                   -                    Џрекращает выполнение
    |                   -                      системной функции
    |                   -                     Џосылает ответ пери-
    |                   -                     ферийному процессу:
    |                   -                      выполнение функции
    |                   -                          прервано
    |     ‚ыходит из состоЯниЯ приостанова
    |            Ђнализирует ответ
    v           Ћбрабатывает сигнал

    ђисунок 13.8. Џрерывание во времЯ выполнениЯ системной функции

                                    388


    Џредположим, например, что периферийный процесс вызывает функцию  чтениЯ
с  терминала,  свЯзанного с центральным процессором, и приостанавливает свою
работу на времЯ выполнениЯ функции процессом-спутником (ђисунок 13.8).  …сли
пользователь  нажимает  клавишу прерываниЯ (break), Ядро –Џ посылает процес-
су-спутнику соответствующий сигнал. …сли спутник находилсЯ в состоЯнии  при-
останова  в  ожидании ввода с терминала порции данных, он немедленно выходит
из этого состоЯниЯ и прекращает выполнение функции read. ‚ своем  ответе  на
запрос  периферийного  процесса спутник сообщает код ошибки и номер сигнала,
соответствующий прерыванию. Џериферийный процесс анализирует ответ  и,  пос-
кольку  в  сообщении  говоритсЯ о поступлении сигнала прерываниЯ, отправлЯет
сигнал самому себе. Џеред выходом из функции read периферийное Ядро осущест-
влЯет проверку поступлениЯ сигналов, обнаруживает сигнал прерываниЯ,  посту-
пивший от процесса-спутника, и обрабатывает его обычным порЯдком. …сли в ре-
зультате  получениЯ  сигнала  прерываниЯ периферийный процесс завершает свою
работу с помощью функции exit, даннаЯ функциЯ берет на себЯ заботу об  унич-
тожении процесса-спутника. …сли периферийный процесс перехватывает сигналы о
прерывании, он вызывает пользовательскую функцию обработки сигналов и по вы-
ходе  из  функции read возвращает пользователю код ошибки. ‘ другой стороны,
если спутник исполнЯет от имени  периферийного  процесса  системную  функцию
stat,  он  не  будет  прерывать ее выполнение при получении сигнала (функции
stat гарантирован выход из любого приостанова, поскольку длЯ нее времЯ  ожи-
даниЯ  ресурса  ограничено).  ‘путник  доводит выполнение функции до конца и
возвращает периферийному процессу номер сигнала. Џериферийный процесс  посы-
лает сигнал самому себе и получает его на выходе из системной функции.
    …сли  сигнал  возник на периферийном процессоре во времЯ выполнениЯ сис-
темной функции, периферийный процесс будет находитьсЯ  в  неведении  относи-
тельно  того,  вернетсЯ ли к нему вскоре управление от процесса-спутника или
же последний перейдет в состоЯние приостанова на неопределенное времЯ. Џери-
ферийный процесс посылает спутнику специальное сообщение, информируЯ  его  о
возникновении сигнала. џдро на –Џ расшифровывает сообщение и посылает сигнал
спутнику,  реакциЯ которого на получение сигнала описана в предыдущих параг-
рафах (аварийное завершение выполнениЯ функции или доведение его до  конца).
Џериферийный  процесс  не  может послать сообщение спутнику непосредственно,
поскольку спутник занЯт исполнением системной функции и не считывает  данные
из линии свЯзи.
    …сли обратитьсЯ к примеру с функцией read, следует отметить, что перифе-
рийный  процесс не имеет представлениЯ о том, ждет ли его спутник ввода дан-
ных с терминала или же выполнЯет другие действиЯ. Џериферийный процесс посы-
лает спутнику сообщение о сигнале: если спутник находитсЯ в состоЯнии приос-
танова с приоритетом, допускающим прерываниЯ, он немедленно выходит из этого
состоЯниЯ и прекращает выполнение системной функции; в противном случае  вы-
полнение функции доводитсЯ до успешного завершениЯ.
    ђассмотрим, наконец, случай поступлениЯ сигнала во времЯ, не свЯзанное с
выполнением  системной  функции.  …сли  сигнал  возник на другом процессоре,
спутник получает его первым и посылает  сообщение  о  сигнале  периферийному
процессу, независимо от того, касаетсЯ ли этот сигнал периферийного процесса
или  нет.  Џериферийное Ядро расшифровывает сообщение и посылает сигнал про-
цессу, который реагирует на него обычным порЯдком. …сли сигнал возник на пе-
риферийном процессоре, процесс выполнЯет стандартные действиЯ, не прибегаЯ к
услугам своего спутника.
    Љогда периферийный процесс посылает сигнал другим  периферийным  процес-
сам,  он  кодирует  сообщение  о  вызове функции kill и посылает его процес-
су-спутнику, который исполнЯет вызываемую функцию локально. …сли часть  про-
цессов, длЯ которых предназначен сигнал, имеет местонахождение на других пе-
риферийных  процессорах, сигнал получат (и прореагируют на его получение вы-
шеописанным образом) их спутники.


                                    389

        13.2 ‘‚џ‡њ ’€ЏЂ NEWCASTL…

    ‚ предыдущем разделе мы рассмотрели тип сильносвЯзанной системы, длЯ ко-
торого характерна посылка всех возникающих на периферийном процессоре  обра-
щений  к  функциЯм  подсистемы управлениЯ файлами на удаленный (центральный)
процессор. ’еперь перейдем к рассмотрению систем с менее сильной свЯзью, ко-
торые состоЯт из машин, производЯщих обращение к файлам, находЯщимсЯ на дру-
гих машинах. ‚ сети, состоЯщей из персональных компьютеров и  рабочих  стан-
ций,  например,  пользователи  часто  обращаютсЯ  к файлам, расположенным на
большой машине. ‚ последующих двух разделах мы рассмотрим такие конфигурации
систем, в которых все системные функции выполнЯютсЯ в локальных подсистемах,
но при этом имеетсЯ возможность обращениЯ к файлам (через функции подсистемы
управлениЯ файлами), расположенным на других машинах.
    „лЯ идентифицированиЯ удаленных файлов в этих системах используетсЯ один
из следующих двух путей. ‚ одних системах в составное имЯ файла  добавлЯетсЯ
специальный  символ: компонента имени, предшествующаЯ этому символу, иденти-
фицирует машину, остальнаЯ часть имени - файл, находЯщийсЯ на  этой  машине.
’ак, например, составное имЯ

    "sftig!/fs1/mjb/rje"

идентифицирует  файл  "/fs1/mjb/rje",  находЯщийсЯ  на машине "sftig". ’акаЯ
схема идентифицированиЯ файла соответствует соглашению, установленному прог-
раммой uucp относительно передачи файлов между системами типа UNIX. ‚ другой
схеме удаленные файлы идентифицируютсЯ добавлением к имени специального пре-
фикса, например:

    /../sftig/fs1/mjb/rje

где "/../" - префикс, свидетельствующий о том, что  файл  удаленный;  втораЯ
компонента  имени файла ЯвлЯетсЯ именем удаленной машины. ‚ данной схеме ис-


        Џроцесс-клиент                      Џроцесс-сервер
+-----------------------------+     +----------------------------+
|                   ’аблица   |     |  Џроцесс-                  |
|  ‘и-библиотека    открытых  |     |  спутник         ‡апрос    |
|                   файлов    |     |  (пользо-        на чтение |
|                   +------+  |     |  вательский      |   |     |
|    +--------------+---   |  |     |  уровень)        |   |     |
|    |              +------+  |     |                  |   |     |
|    |  локальный   |      |  |     |    +-------------+   |     |
|    |              +------+  |     |    |                 |     |
|    |         +----+---   |  |     |    |                 |     |
|    |         |    +------+  |     |    |                 |     |
|    |         |    |      |  |     |    |                 |     |
|    |         |    +------+  |     |    |                 |     |
|    |         +-----+        |     |    |                 |     |
+----+---------------+--------+     +----+-----------------+-----+
     |               | удаленный         |                 |
+----+---------------+--------+     +----+-----------------+-----+
|    |              ‘етевой   |     |    |             ‘етевой   |
|  џдро             интерфейс |     |  џдро            интерфейс |
|                    |        |     |                      |     |
+--------------------+--------+     +----------------------+-----+
                     |              с е т ь                |
                     +-------------------------------------+

    ђисунок 13.9. ”ормулирование запросов к файловому серверу (процессору)

                                    390


пользуетсЯ привычный синтаксис имен файлов в системе UNIX, поэтому в отличие
от первой схемы здесь пользовательским программам нет  необходимости  прино-
равливатьсЯ  к  использованию имен, имеющих необычную конструкцию (см. [Pike
85]).
    ‚сю оставшуюсЯ часть раздела мы посвЯтим  рассмотрению  модели  системы,
использующей  свЯзь типа Newcastle, в которой Ядро не занимаетсЯ распознава-
нием удаленных файлов; эта функциЯ полностью возлагаетсЯ на подпрограммы  из
стандартной  ‘и-библиотеки,  выполнЯющие в данном случае роль системного ин-
терфейса. ќти подпрограммы анализируют первую компоненту имени файла, в обо-
их описанных способах идентифицированиЯ содержащую признак удаленности  фай-
ла.  ‚  этом состоит отступление от заведенного порЯдка, при котором библио-
течные подпрограммы не занимаютсЯ синтаксическим разбором  имен  файлов.  Ќа
ђисунке  13.9 показано, каким образом формулируютсЯ запросы к файловому сер-
веру. …сли файл локальный, Ядро локальной системы обрабатывает запрос  обыч-
ным способом. ђассмотрим обратный случай:

    open("/../sftig/fs1/mjb/rje/file",O_RDONLY);

Џодпрограмма open из ‘и-библиотеки анализирует первые две компоненты состав-
ного  имени  файла  и  узнает,  что  файл следует искать на удаленной машине
"sftig". —тобы иметь информацию о том, была ли ранее у процесса свЯзь с дан-
ной машиной, подпрограмма заводит специальную структуру, в которой запомина-
ет этот факт, и в случае отрицательного ответа устанавливает свЯзь с  файло-
вым сервером, работающим на удаленной машине. Љогда процесс формулирует свой
первый запрос на дистанционную обработку, удаленный сервер подтверждает зап-
рос,  в случае необходимости ведет запись в полЯ пользовательского и группо-
вого кодов идентификации и создает процессспутник, который  будет  выступать
от имени процесса-клиента.
    —тобы выполнЯть запросы клиента, спутник должен иметь на удаленной маши-
не те же права доступа к файлам, что и клиент. „ругими словами, пользователь
"mjb" должен иметь и к удаленным, и к локальным файлам одинаковые права дос-
тупа. Љ сожалению, не исключена возможность того, что код идентификации кли-
ента  "mjb"  может  совпасть с кодом идентификации другого клиента удаленной
машины. ’аким образом, администраторам систем на работающих в  сети  машинах
следует либо следить за назначением каждому пользователю кода идентификации,
уникального  длЯ  всей сети, либо в момент формулированиЯ запроса на сетевое
обслуживание выполнЯть преобразование кодов. …сли это не будет сделано, про-
цесс-спутник будет иметь на удаленной машине права другого клиента.
    Ѓолее деликатным вопросом ЯвлЯетсЯ получение в отношении работы  с  уда-
ленными файлами прав суперпользователЯ. ‘ одной стороны, клиент-суперпользо-
ватель  не  должен иметь те же права в отношении удаленной системы, чтобы не
вводить в заблуждение средства защиты удаленной системы. ‘  другой  стороны,
некоторые  из  программ,  если  им  не предоставить права суперпользователЯ,
просто не смогут работать. Џримером такой программы ЯвлЯетсЯ программа mkdir
(см. главу 7), создающаЯ новый каталог. “даленнаЯ система  не  разрешила  бы
клиенту  создавать новый каталог, поскольку на удалении права суперпользова-
телЯ не действуют. Џроблема созданиЯ удаленных  каталогов  служит  серьезным
основанием  длЯ  пересмотра  системной функции mkdir в сторону расширениЯ ее
возможностей в автоматическом  установлении  всех  необходимых  пользо