Модель клиент-сервер

Система VM/370 сильно выигрывает в простоте благодаря переносу значитель­ной части кода традиционной операционной системы (обеспечивающего расши­ренную машину) в верхний уровень, систему CMS. Однако VM/370 и при этом останется сложной комплексной программой, потому что моделирование не­скольких виртуальных 370-х машин само по себе не так просто (особенно если вы хотите сделать это достаточно эффективно).

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

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

Другое преимущество модели клиент-сервер заключается в ее простой адап­тации к использованию в распределенных системах (рис. 1.16). Если клиент об­щается с сервером, посылая ему сообщения, клиенту не нужно знать, обрабаты­вается ли его сообщение локально на его собственной машине, или оно было послано по сети серверу на удаленной машине. С точки зрения клиента происхо­дит одно и то же в обоих случаях: запрос был послан и на него получен ответ.

Рассказанная выше история о ядре, управляющем передачей сообщений от клиентов к серверам и назад, не совсем реалистична. Некоторые функции опера­ционной системы, такие как загрузка команд в регистры физических устройств ввода/вывода, трудно, если вообще возможно, выполнить из программ в про­странстве пользователя. Есть два способа разрешения этой проблемы. Первый заключается в том, что некоторые критические серверные процессы (например, драйверы устройств ввода/вывода) действительно запускаются в режиме ядра, с полным доступом к аппаратуре, но при этом общаются с другими процессами при помощи обычной схемы передачи сообщений.

Второй способ состоит в том, чтобы встроить минимальный механизм обра­ботки информации в ядро, но оставить принятие политических решений за сер­верами в пользовательском пространстве [53]. Например, ядро может опознавать сообщения, посланные по определенным адресам. Для ядра это означает, что нужно взять содержимое сообщения и загрузить его, скажем, в регистры ввода/ вывода некоторого диска для запуска операции чтения диска. В этом приме­ре ядро даже может не обследовать байты сообщения, если они оказались допу­стимы или осмысленны; оно может вслепую копировать их в регистры диска. (Очевидно, должна использоваться некоторая схема, ограничивающая круг про­цессов, имеющих право отправлять подобные сообщения). Разделение между механизмом и политикой является очень важным понятием, встречаются в операционных системах в различном контексте постоянно.

Источник: Википедия

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