Архитектура типа клиент-сервер на основе микроядра

⇐ ПредыдущаяСтр 3 из 4Следующая ⇒

Архитектура типа клиент-сервер в настоящее время является наиболее совершенной с точки зрения расширяемости и переносимости операционных систем.

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

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

Получив запрос от клиента, сервер выполняет его, при этом он сам может обратиться за услугами к другим серверам. После выполнения запроса сервер отсылает клиенту сообщение о завершении задания и результаты работы.

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

Для архитектуры типа клиент-сервер характерно горизонтальное разделение функциональности между равноправными серверами, вместо вертикального иерархического распределения в многоуровневой архитектуре. При этом, каждый сервер отвечает за выполнение отдельной достаточно простой операции и ни в коей мере не является эквивалентом уровня в многоуровневой архитектуре.

Таким образом, архитектура клиент-сервер обеспечивает следующие основные преимущества:

• переносимость операционной системы, т.к. серверы, работающие в пользовательском режиме, аппаратно независимы;

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

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

Указанные преимущества делают архитектуру клиент-сервер наиболее подходя-щей для построения операционных систем, удовлетворяющих современным требованиям.

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

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

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

Такая организация операционной системы позволяет достичь удачного компромисса гибкость/производительность, и, в конечном итоге, получить производительность, близкую к производительности классической многоуровневой системы в сочетании с максимально простой переносимостью и расширяемостью.

5. Процессы (понятие процесса, модель процесса)

Основным понятием, связанным с ОС является процесс – абстрактное понятие, описывающее работу программы. Процесс – это активность некоторого рода. У него есть программа, входные и выходные данные, а также состояние. Один процессор переключается между различными процессами, используя некий алгоритм планирования для определения момента переключения от одного процесса к другому.

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

Модель процесса:

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

Когда время, отведенное для работы с одним процессом проходит, процессор, переходит на другой процесс, выбора следующего процесса зависит от логического алгоритма (например приоритеты)

6. Состояния процессов (диаграммы состояний процессов)

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

Модель с пятью состояниями:

· Выполняющийся. Процесс, который выполняется в текущий момент времени. В настоящей главе предполагается, что на компьютере установлен только один процессор, поэтому в этом состоянии может находиться только один процесс.

· Готовый к выполнению. Процесс, который может быть запущен, как только для этого представится возможность.

· Блокированный. Процесс, который не может выполняться до тех пор, пока не произойдет некоторое событие, например завершение операции ввода-вывода.

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

· Завершающийся. Процесс, удаленный операционной системой из пула выполнимых процессов.

7. Потоки (модель потока, использование потоков, реализация потоков)

В обычных операциях каждому процессу соответствует адресное пространство и одиночный управляющий поток.

Модель потока:

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

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

· Счетчик команд, отслеживающий порядок выполнения действий;

· Регистры, в которых хранятся текущие переменные;

· Стэк, содержащий протокол выполнения процесса.

Процессы используются для группировки ресурсов, а потоки являются объектами, поочередно исполняющимися на ЦП. Несколько потоков, работающих параллельно в одном процессе, схожи несколькими процессами, идущими параллельно на одном компьютере. Потоки разделяют адресное пространство, открытые файлы и другие ресурсы. Процессы совместно используются физической памятью, дисками, принтерами и другими ресурсами. Потоки обладают некоторыми свойствами процессов, поэтому их иногда называют упрощенными процессами.

Многопоточность описывает использование нескольких потоков в одном процессе.

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

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

Действующий поток взаимодействует с процессором. Блокированный поток ожидает некоторого события, которое его разблокирует. Поток в состоянии готовности будет запущен, как только до него дойдет очередь.

Использование потоков:

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

В случае потоков придется добавить еще один элемент: возможность совместного использования параллельными объектами адресного пространства и всех содержащих в нем данных. Для определенных приложений эта возможность является существенной, и в таких случаях схема параллельных процессов не подходит.

Еще одним аргументом в пользу потоков является легкость их создания и уничтожения. В большинстве систем на создание потока уходит примерно в 100 раз меньше времени, чем на создание процесса.

Третьим аргументом является производительность. Концепция потоков не дает увеличения производительности, если все они ограничены возможностями процессора. Но когда имеется одновременная потребность в выполнении большого объема вычислений и операций ввода-вывода, наличие потоков позволяет совмещать эти виды деятельности во времени, тем самым увеличивая общую скорость работы приложения. Концепция потоков полезна в системах с несколькими процессорами, где возможен настоящий параллелизм.

Реализация потоков:

Есть два способа реализации пакета потоков: в пространстве пользователя и ядре. Возможна смешанная реализация.

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

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

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

На уровне ядра:

В программе, работа которой полностью основана на потоках, работающих на уровне ядра, все действия по управлению потоками выполняются ядром. В области приложений отсутствует код, предназначенный для управления потоками. Вместо него используется интерфейс прикладного программирования (application programming interface — API) средств ядра, управляющих потоками. Примерами такого подхода являются операционные системы OS/2, Linux и W2K.

Любое приложение при этом можно запрограммировать как многопоточное; все потоки приложения поддерживаются в рамках единого процесса. Ядро поддерживает информацию контекста процесса как единого целого, а также контекстов каждого отдельного потока процесса. Планирование выполняется ядром исходя из состояния потоков. С помощью такого подхода удается избавиться от двух упомянутых ранее основных недостатков потоков пользовательского уровня. Во-первых, ядро может одновременно осуществлять планирование работы нескольких потоков одного и того же процесса на нескольких процессорах. Во-вторых, при блокировке одного из потоков процесса ядро может выбрать для выполнения другой поток этого же процесса. Еще одним преимуществом такого подхода является то, что сами процедуры ядра могут быть многопоточными.

Различие во времени выполнения потоков на уровне ядра и потоков на пользовательском уровне более чем на порядок превосходит по величине различие во времени выполнения потоков на уровне ядра и процессов.

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

Диспетчеризация потоков

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

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

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

⇐ Предыдущая 1 234 Следующая ⇒