Подсистема управления процессами
Она отвечает за синхронизацию и взаимодействие процессов, распределение памяти и планирование выполнения процессов. Для всех этих целей в подсистему управления процессами включены три модуля, которые наглядно продемонстрированы на схеме. Хорошим примером взаимодействия подсистем управления файлами и процессами является загрузка файла на исполнение. В этом случае подсистеме управления процессов требуется обратиться к коллеге, чтобы считать исполняемые файлы. Вызовы, служащие для работы с процессами: fork (создает новый процесса), exec (выполняет процесс), exit (завершает исполнение процесса), wait (один из способов синхронизации), brk (управляет памятью, выделенной процессу), signal (обработчики исключений) и др. Следующие два модуля являются очень важными в понимании всей подсистемы управления процессами. Первый — модуль распределения памяти, позволяет избежать нехватки оперативной памяти. Хотя механизм свопинга и файлов подкачки (технически правильно это, кстати, называется виртуальной памятью) уже ни для кого не секрет, в тени остается другой факт: операционная система (в лице описываемой подсистемы) может либо скидывать все данные, относящиеся к конкретному процессу, на диск, либо скидывать страницы памяти (страничное замещение). Таким образом, модуль распределения памяти выполняет очень важную функцию — он определяет какому процессу сколько выделить памяти. Виртуальная память была изобретена в 1962 году, в Англии при создании суперкомпьютера Atlas. В большинстве современных компьютеров оперативная память не так велика, как используемое процессором адресное пространство. Размер ОЗУ типичного персонального компьютера варьируется от десятков до сотен мегабайт. При запуске программа загружается с какого-либо накопителя в оперативную память. Если же программа не помещается в ОЗУ, то те её части, которые в данный момент не выполняются, хранятся во вторичном запоминающем устройстве, чаще всего винчестере, и такая память называется виртуальной. Безусловно, перед выполнением необходимая часть программы должна быть перемещена в оперативную память. Данные функции выполняет ядро операционной системы (диспетчер виртуальной памяти, находящийся в микроядре). И для программы и для пользователя эти действия прозрачны. Естественно, на запросы к виртуальной памяти уходит гораздо большее время, нежели к ОЗУ. Второй модуль — планировщик. Его задача не менее важна. UNIX — мультизадачная ОС, то есть одновременно может выполняться множество процессов. Мы, однако, знаем, что в фиксированный момент времени на одном процессоре может выполняться только одна команда. Именно поэтому нужен виртуальный рефери, который будет определять, какому процессу исполняться сейчас, а какому — через секунду. На практике же планировщик переключает контекст, то есть перед тем, как остановить исполнение какого-то процесса, он запоминает состояние регистров, памяти и т. д., а уже после этого запускает другой процесс в его собственном адресном пространстве. И еще один тонкий момент: каждый запущенный процесс «думает», что он единственный. Дополнительно существует механизм приоритетов. Очевидно, чем выше приоритет, тем быстрее начнет исполняться процесс. Процессы могут также обмениваться между собой информацией. В случае их синхронного взаимодействия синхронизацию осуществляет модуль взаимодействия (например, функция wait). Последний уровень — аппаратный контроль. На данном уровне происходит обработка прерываний и связь ядра с железом. Здесь следует отметить лишь пару моментов, во-первых, прерывания могут «прерывать» работу процессора и требовать внимания к себе (после этого процессор без проблем возвращается к выполнению оставленных процессов), а, во-вторых, обработку прерываний осуществляют специальные функции ядра. На архитектуре микроядра построены также FreeBSD и Mac OS X. Монолитные же ядра используются еще и в Linux. Они оптимизированы для более высокой производительности с минимальными контекстными переключениями. Такая архитектура упрощает поддержку кода ядра для разработчиков, но требует перекомпиляции ядра при добавлении новых устройств. Следует отметить, что описанные здесь различия являются «классическими», на практике монолитные ядра могут поддерживать модульность (что зачастую и происходит), а микроядра могут требовать перекомпиляции. Ядро UNIX/Linux имеет два вида исключений, которые обычно называют «oops» и «panic». Почти в каждой операционной системе паника происходит в тех случаях, когда ядро обнаруживает серьезную неисправность. Если система каким-либо образом повредила сама себя, ей требуется остановиться немедленно, пока она не произведет необратимых критических изменений (типа уничтожения файловой системы). Везде, где только возможно, UNIX/Linux пытается детектировать проблему и справиться с ней без остановки всей системы. Например, многие ситуации типа «oops» приводят к завершению процесса, который нормально запустился, но потом зациклил систему. Бывают, однако, ситуации, когда все настолько плохо, что полная паника является наилучшим выходом. Считается, что пользователи стабильных версий ядра не должны встречать ни «паник», ни «oops». Но в реальном мире они иногда происходят. Недавно найденный «TF-баг» является хорошим примером паники. Процессор пытается передать управление процессу, которого не существует. Это приводит к краху всей системы. В данном случае, у системы нет другой альтернативы, чем запаниковать. Ядро, поставляемое с Red Hat Linux 7.3 (и некоторыми другими дистрибутивами), содержит баг в файловой системе ext3. Эта ошибка приводит к «oops», завершая время от времени некоторые процессы (также этот баг приводит к замедлению всей системы). Хотя данная ошибка уже исправлена (патч есть и в обновлении от Red Hat), этот случай познакомил многих пользователей с ошибками типа «oops». Рис. 6. Фундаментальная архитектура операционной системы GNU/Linux На верхнем уровне находится пользовательское пространство (пространство приложений). Здесь исполняются приложения пользователя. Под пользовательским пространством располагается пространство ядра. Здесь функционирует ядро Linux. Имеется также библиотека GNU C (glibc). Она предоставляет интерфейс системных вызовов, который обеспечивает связь с ядром и дает механизм для перехода от приложения, работающего в пространстве пользователя, к ядру. Это важно, поскольку ядро и пользовательское приложение располагаются в разных защищенных адресных пространствах. При этом, в то время как каждый процесс в пространстве пользователя имеет свое собственное виртуальное адресное пространство, ядро занимает одно общее адресное пространство. Ядро Linux можно, в свою очередь, разделить на три больших уровня:
- Наверху располагается интерфейс системных вызовов, который реализует базовые функции, например, чтение и запись;
- Ниже интерфейса системных вызовов располагается код ядра, точнее говоря, архитектурно-независимый код ядра. Этот код является общим для всех процессорных архитектур, поддерживаемых Linux.
- Еще ниже располагается архитектурно-зависимый код, образующий т.н. BSP (Board Support Package — пакет поддержки аппаратной платформы). Этот код зависит от процессора и платформы для конкретной архитектуры.
Методы интерфейса системных вызовов (SCI) Реальная архитектура Linux не вполне следует «идеальной» модели, показанной на рисунке. Например, механизм обработки системных вызовов (переход от пространства пользователя к пространству ядра) может быть разным для разных архитектур. В более современных процессорах с архитектурой x86, имеющих поддержку инструкций виртуализации, этот процесс осуществляется эффективнее, чем в старых процессорах x86, где применяется традиционный подход с использованием прерывания int 80h.
Для продолжения скачивания необходимо пройти капчу:
Подсистема управления процессами.
Запущенная на выполнение программа порождает в системе один или более процессов (или задач).
Подсистема управления процессами контролирует:
- Создание и удаление процессов.
- Распределение системных ресурсов (памяти, вычислительных ресурсов) между процессами.
- Синхронизацию процессов.
- Межпроцессорное взаимодействие.
Подсистема ввода/вывода.
Подсистема ввода/вывода выполняет запросы файловой подсистемы и подсистемы управления процессами для доступа к ПУ (дискам, магнитным лентам, терминалам и т. д.). Она обеспечивает необходимую буферизацию данных и взаимодействует с драйверами устройств – специальными модулями ядра, непосредственно обслуживающими внешние устройства.
Файловая система ос unix.
Понятие файла в ОС UNIX максимально унифицировано. Файлами считаются обычные файлы, каталоги, каналы; внешние устройства представляются в виде специальных файлов: байт-ориентированных (например терминал, принтер, последовательный порт) и блок-ориентированных (накопители на магнитных дисках) в зависимости от единиц передаваемых данных. Доступ к файлам любого вида однотипен, то есть доступ к внешним устройствам такой же как к обычным файлам. Такой подход обеспечивает независимость программы пользователя от особенностей ввода-вывода на конкретное устройство. Помимо этого, файлы в UNIX определяют привилегии пользователей, поскольку права пользователя контролируются с помощью прав доступа к файлам. Как и во многих ОС-ах, в UNIX файлы организованы в виде древовидной структуры, называемой файловой системой. Корнем этого дерева является корневой каталог, имеющий имя «/». Имена всех остальных файлов содержат путь – список каталогов (ветвей), которые необходимо пройти, чтобы достичь файла. Таким образом, полное имя любого файла начинается с «/» и не содержит идентификатора устройства, на котором он фактически хранится. UNIX допускает существование нескольких файловых систем, присоединенных к корневому каталогу. В UNIX существует 6 типов файлов, различающихся по функциональному назначению и действиям операционной системы при выполнении операций над файлами.
- Обычный файл (regular file).
- Каталог (directory).
- Специальный файл устройства (special device file).
- FIFO или именованный канал (named pipe).
- Связь (link).
- Сокет.
Обычный файл представляет собой наиболее общий тип файлов, содержащий данные в некотором формате. Для ОС такие файлы представляют собой просто последовательность байтов. Эти файлы обрабатываются прикладной программой. Каталог – это файл, содержащий имена находящихся в нем файлов, а также указатели на дополнительную информацию – метаданные, позволяющие ОС производить операции над этими файлами. Каталоги определяют положение файла в дереве файловой системы, поскольку сам файл не содержит информации о своем местонахождении. Любая программа может прочитать содержание каталога, но только ядро имеет право на запись в каталог. По существу каталог представляет собой таблицу, каждая запись которой соответствует некоторому файлу. /home/andrei 10245 . — текущий каталог 12432 .. — родительский каталог
- file1.txt
12567 first 13678 report 
номер имя метаданные файла Специальный файл устройства обеспечивает доступ к физическому устройству. В UNIX различают символьные (character) и блочные (block) файлы устройств. Доступ к устройствам осуществляется путем открытия, чтения и записи в специальный файл устройства. Символьные файлы устройств используются для не буферизованного обмена данными с устройством, в противоположность этому блочные файлы позволяют производить обмен данными в виде пакетов фиксированной длины – блоков. Доступ к некоторым устройствам может осуществляться как через символьные, так и через блочные специальные файлы. FIFOили именованный канал – это файл, используемый для связи между процессами. FIFO впервые появился в System V UNIX, и большинство современных систем поддерживают этот механизм. Связь. Как уже отмечалось, каталог содержит имена файлов и указатели на их метаданные. В то же время сами метаданные не содержат ни имени файла, ни указателя на его имя. Такая архитектура позволяет одному файлу иметь несколько имен в файловой системе. Имена тесно связаны с метаданными и, соответственно, с данными файла, в то время как файл существует независимо от того, как его называют. Такая связь имени файла с его данными называется жесткой связью (hard link). Жесткая связь является естественной формой связи имени файла с его метаданными и не принадлежит к особому типу файла. Особым типом файла является символическая связь, позволяющая косвенно адресовать файл. Символическая связь адресует файл, который, в свою очередь, ссылается на другой файл. Данные файла, являющиеся символической связью, содержат только имя целевого файла, и ОС работает с такими файлами не так, как с обычными. Сокеты предназначены для взаимодействия между процессами. Интерфейс сокетов часто используется для доступа к сети TCP/IP. В системах, ветви BSDINIX на базе сокетов реализована система межпроцессорного взаимодействия, с помощью которой работают многие системные сервисы, например, система печати.