Вопрос 40.1. Права доступа на файлы и директории в ОС Unix. Команды смен прав доступа

В операционной системе UNIX существуют три базовых класса доступа к файлу, в каждом из которых установлены соответствующие

права доступа:

· User access (u) Для владельца-пользователя файла

· Group access (g) Для членов группы, являющейся владельцем файла

· Other access (о) Для остальных пользователей (кроме суперпользователя)

UNIX поддерживает три типа прав доступа для каждого класса: на чтение (read, обозначается символом r), на запись (write, обозначается символом w) и на выполнение (execute, обозначается символом х). С помощью команды Is -l можно получить список прав доступа к файлу:

-rw-r--r-- andy group Dec 22 19:13 Report.txt.1
drwxr-xr-- andy group Aug 15 11:03 Temp
-rwxr-xr--- andy group Dec 22 15:13 a.out
rw-r--r-- andy group Feb 11 09:13 Cont.c

Права доступа листинга отображаются в первой колонке (за исключением первого символа, обозначающего тип файла). Наличие права доступа обо­значается соответствующим символом, а отсутствие - символом '-'. Рас­смотрим, например, права доступа к файлу a.out:

Тип файла Права владельца-пользователя Права владельца-группы Права остальных пользова­телей
- Rwx R-x R--
Обычный файл Чтение, запись, выполнение Чтение и выполнение Только чтение

Вопрос 40.1. Права доступа на файлы и директории в ОС Unix. Команды смен прав доступа - №1 - открытая онлайн библиотека Вопрос 40.1. Права доступа на файлы и директории в ОС Unix. Команды смен прав доступа - №1 - открытая онлайн библиотека Права доступа могут быть изменены только владельцем файла или супер­пользователем (superuser) - администратором системы. Для этого исполь­зуется команда chmod(l). Ниже приведен общий формат этой команды.

U

Вопрос 40.1. Права доступа на файлы и директории в ОС Unix. Команды смен прав доступа - №3 - открытая онлайн библиотека Вопрос 40.1. Права доступа на файлы и директории в ОС Unix. Команды смен прав доступа - №3 - открытая онлайн библиотека Вопрос 40.1. Права доступа на файлы и директории в ОС Unix. Команды смен прав доступа - №3 - открытая онлайн библиотека Вопрос 40.1. Права доступа на файлы и директории в ОС Unix. Команды смен прав доступа - №3 - открытая онлайн библиотека Chmod G + r

O - w

A = x

В качестве аргументов команда принимает указание классов доступа ('u' - владелец-пользователь, 'g' - владелец-группа, 'о' - остальные пользовате­ли, 'а' - все классы пользователей), права доступа ('r' - чтение, ‘w’ - за­пись и 'х' - выполнение) и операцию, которую необходимо произвести ('+' - добавить, '-' - удалить и '=' - присвоить) для списка файлов file 1, file2 и т. д. Например, команда

$ chmod g-wx ownfile

лишит членов группы-владельца файла ownfile права на запись и выполне­ние этого файла.

В одной команде можно задавать различные права для нескольких классов доступа, разделив их запятыми.

Приведем еще несколько примеров:

$ chmod a+w text Предоставить право на запись для всех пользователей
$ chmod go=r text Установить право на чтение для всех пользо­вателей, за исключением владельца
$ chmod g+x-w runme Добавить для группы право на выполнение файла runme и снять право на запись
$ chmod u+w, og+r-w textl text2 Добавить право записи для владельца, право на чтение для группы и остальных пользова­телей, отключить право на запись для всех пользователей, исключая владельца

Последний пример демонстрирует достаточно сложную установку прав доступа. Вы можете установить сразу все девять прав доступа, используя числовую форму команды chmod(l):

$ chmod 754 *

Число определяется следующим образом: нужно представить права доступа в двоичном виде (0 - отсутствие соответствующего права, 1 - его нали­чие) и каждую триаду, соответствующую классу доступа, в свою очередь преобразовать в десятичное число.

Владелец Группа Остальные
R W X r - х r - -

Таким образом, приведенный пример эквивалентен следующей символь­ной форме chmod(l):

$ chmod u=rwx, g=rx, o=r

Значение прав доступа различно для разных типов файлов. Для файлов опе­рации, которые можно производить, следуют из самих названий прав досту­па. Например, чтобы просмотреть содержимое файла командой cat(l), поль­зователь должен иметь право на чтение (r). Редактирование файла, т. е. его изменение, предусматривает наличие права на запись (w). Наконец, для того чтобы запустить некоторую программу на выполнение, вы должны иметь соответствующее право (х). Исполняемый файл может быть как скомпили­рованной программой, так и скриптом командного интерпретатора shell. В последнем случае вам также понадобится право на чтение, поскольку при выполнении скрипта командный интерпретатор должен иметь возможность считывать команды из файла. Все сказанное, за исключением, пожалуй, права на выполнение, имеющего смысл лишь для обычных файлов и ката­логов, справедливо и для других типов файлов: специальных файлов уст­ройств, именованных каналов, и сокетов. Например, чтобы иметь возмож­ность распечатать документ, вы должны иметь право на запись в специаль­ный файл устройства, связанный с принтером. Для каталогов эти права имеют другой смысл, а для символических связей они вообще не использу­ются, поскольку контролируются целевым файлом.

Права доступа для каталогов не столь очевидны. Это в первую очередь связано с тем, что система трактует операции чтения и записи для ката­логов отлично от остальных файлов. Право чтения каталога позволяет вам получить имена (и только имена) файлов, находящихся в данном каталоге. Чтобы получить дополнительную информацию о файлах каталога (например, подробный листинг команды Is -/), системе придется "загля­нуть" в метаданные файлов, что требует права на выполнения для катало­га. Право на выполнения также потребуется для каталога, в который вы захотите перейти (т. е. сделать его текущим) с помощью команды cd (1). Это же право нужно иметь для доступа ко всем каталогам на пути к ука­занному. Например, если вы установите право на выполнения для всех пользователей в одном из своих подкаталогов, он все равно останется не­доступным, пока ваш домашний каталог не будет иметь такого же права.

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

$ pwd Где мы находимся?

/home/andrei

$ mkdir darkroom Создадим каталог

$ Is - 1 Получим его атрибуты

-rwxr--r- 2 andy group 65 Dec 22 19:13 darkroom

$ chmod a-r+x darkroom Превратим его в "темный" каталог
$ Is - 1 Получим его атрибуты

-wx-х - х 2 andy

$ ср filel darkroom Поместим в каталог darkroom некоторый файл

$ cd darkroom Перейдем в этот каталог

$ Is -1 darkroom Попытаемся получить листинг каталога

##permission denied Увы...

$ cat filel

ok

group 65 Dec 22 19:13 darkroom

Тем не менее, заранее зная имя файла (file1), можно работать с ним (например, прочитать, если есть соответ­ствующее право доступа)

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

Итак, для выполнения операции над файлом имеют значение класс досту­па, к которому вы принадлежите, и права доступа, установленные для этого класса. Поскольку для каждого класса устанавливаются отдельные права доступа, всего определено 9 прав доступа, по 3 на каждый класс.

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

· Если операция запрашивается суперпользователем, доступ разрешает­ся. Никакие дополнительные проверки не производятся. Это позволяет администратору иметь неограниченный доступ ко всей файловой системе.

· Если операция запрашивается владельцем файла, то:

если требуемое право доступа определено (например, при опера­ции чтения файла установлено право на чтение для владельца-пользователя данного файла), доступ разрешается,

в противном случае доступ запрещается.

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

если требуемое право доступа определено, доступ разрешается,

в противном случае доступ запрещается.

· Если требуемое право доступа для прочих пользователей (other) установлено, доступ разрешается, в противном случае доступ запрещается.

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

----rw-r-- 2 andy group 65 Dec 22 19:13 file1

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

Вопрос 47.1. Расширенные атрибуты файлов и директорий (setuid, setguid, sticky). Списки прав доступа на файлы (ACL). Алгоритмы планирования процессов

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

Дополнительные атрибуты также устанавливаются утилитой chmod(l), но вместо кодов 'г', 'w' или 'x' используются коды из табл. 1.3. Например, для установки атрибута SGID для файла filel необходимо выполнить команду

$ chmod g+s filel.

В табл. 1.3 приведены дополнительные атрибуты для файлов, и показано, как они интерпретируются операционной системой.

Код Название Значение
t Sticky bit Сохранить образ выполняемого файла в памяти после завершения выполнения
s SetUID, SUID Установить UID процесса при выполнении
s SetGID, SGID Установить GID процесса при выполнении
Блокирование Установить обязательное блокирование файла

Таблица 1.3. Дополнительные атрибуты для обычных файлов

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

Атрибуты (или флаги) SUID и SGID позволяют изменить права пользова­теля при запуске на выполнение файла, имеющего эти атрибуты. При этом привилегии будут изменены (обычно расширены) лишь на время вы­полнения и только в отношении этой программы.

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

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

$ Is -IFa /usr/bin/passwd

-r-sr-sr-x 3 root sys 15688 Oct 25 1995 /usr/bin/passwd

Понятно, что требования по безопасности для такой программы должны быть повышены. Утилита passwd(l) должна производить изменение пароля только пользователя, запустившего ее, и не позволять никакие другие опе­рации (например, вызов других программ).

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

Однако вернемся к обсуждению дополнительных атрибутов для каталогов (табл. 1.4).

Таблица 1.4.Дополнительные атрибуты для каталогов

Код Название Значение
t Sticky bit Позволяет пользователю удалять только файлы, кото­рыми он владеет или имеет права на запись
S Set GID, SGID Позволяет изменить правило установки владельца-группы создаваемых файлов, аналогично реализован­ному в BSD UNIX

При обсуждении прав доступа отмечалось, что предоставление права на запись в каталог дает достаточно большие полномочия. Имея такое право, пользователь может удалить из каталога любой файл, даже тот, владельцем которого он не является и в отношении которого не имеет никаких прав, установка атрибута Sticky bit для каталога позволяет установить дополнительную защиту файлов, находящихся в каталоге. Из такого каталога пользователь может удалить только файлы, которыми он владеет, или на которые он имеет явное право доступа на запись, даже при наличии права на запись в каталог. Примером может служить каталог /tmp,который является открытым на запись для всех пользователей, но в котором может оказаться нежелательной возможность удаления пользователем чужих временных файлов.

Атрибут SGID также имеет иное значение для каталогов. При установке этого атрибута для каталога вновь созданные файлы этого каталога будут следовать владельца-группу по владельцу-группе каталога. Таким образомдля UNIX версии System V удается имитировать поведение систем версии BSD, для которых такое правило наследования действует по умол­чанию.

Посмотреть наличие дополнительных атрибутов можно с помощью под­робного списка файлов:

$ is -1

drwxrwxrwxt 5 sys sys 367 Dec 19 20:29 /tmp

-r-sr-sr-x 3 root sys 15688 Oct 25 1995 /usr/bin/passwd

Таблица 1.5.Операции изменения атрибутов файла

Операция Команда/системный вызов Кому разрешено вызов
Изменение прав доступа chmod(1) Владелец
Изменение дополнитель­ного атрибута Sticky bit chmod(1) суперпользователь
Изменение дополнитель­ного атрибута SGID chmod(1) владелец, причем его GID так­же должен совпадать с иден­тификатором группы файла

Access Control List

ACL - это список лиц или групп с указанием того что они могут делать, такой список есть у каждого ресурса.
Пример - папка на диске.
У процесса есть идентификатор пользователя, от лица которого он выполняется. Соответственно, при выполнении процесса таким образом проверяются полномочия. Иногда нужно что бы файл, запущенный обычным пользователем, обладал полномочиями администратора - для этого используются setuid и setguid - они задают пользователя от которого будет исполняться процесс вне зависимости от исполнителя;
stiky bit - задается на директорию - задает пользователя для файлов который создаются в этой директории.

Алгоритмы планирования процессов

Планирование процессов включает в себя решение следующих задач:

· Определение момента времени для смены выполняемого процесса

· Выбор процесса на выполнение из очереди готовых процессов

· Переключение контекстов старого и нового процессов (обычно решается аппаратно)

Различные алгоритмы планирования решают эти задачи по-разному.

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

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

Современные системы – с вытесняющей многозадачностью.

Существуют механизмы прерывания, основанные на:

· Переключение по времени. Встраивается центральный таймер, который подает сигнал прерывания; может произойти в конкретный момент реального времени системы или по истечению кванта времени; кванты, выделяемые CPU могут быть постоянными и переменными. Переменный квант может динамически изменяться или вычисляться по формулам. Если квант маленький, то контекст очень быстро дергается. Большой квант – большая задержка.

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

Приоритет = (время ожидания + время обслуживания) / время обслуживания.

Планирование с абсолютными приоритетами.

· Если появился процесс наивысшим приоритетом, все остальные приоритеты прерываются.

· Процедура выбора

FIFO – first in, first out

LIFO – last in, first out

RR – round robin – циклическая процедура обслуживания

SJL – shortlist job first – кратчайшие задания – первыми

SRT – shortlist remaining time – по наименьшему оставшемуся до завершения времени

HPF – highest priority first

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

Алгоритмы планирования процессов

Как и оперативная память, процессор является разделяемым ресурсом, который должен быть справедливо распределен между конкурирующими процессами. Планировщик процессов как раз и является той подсистемой ядра, которая обеспечивает предоставление процессорных ресурсов процессам, выполняющимся в операционной системе. UNIX является систе­мой разделения времени, это означает, что каждому процессу вычисли­тельные ресурсы выделяются на ограниченный промежуток времени, по­сле чего они предоставляются другому процессу и т. д. Максимальный временной интервал, на который процесс может захватить процессор, на­зывается временным квантом (time quantum или time slice). Таким образом создается иллюзия, что процессы выполняются одновременно, хотя в дей­ствительности в каждый момент времени выполняется только один (на однопроцессорной системе) процесс.

UNIX является многозадачной системой, а это значит, что одновременно выполняются несколько приложений. Очевидно, что приложения предъ­являют различные требования к системе с точки зрения их планирования и общей производительности. Можно выделить три основных класса при­ложений:

· Интерактивные приложения. К этому классу относятся командные интерпретаторы, текстовые редакторы и другие программы, непо­средственно взаимодействующие с пользователем. Такие приложения большую часть времени обычно проводят в ожидании пользователь­ского ввода, например, нажатия клавиш клавиатуры или действия мышью. Однако они должны достаточно быстро обрабатывать такие действия, обеспечивая комфортное для пользователя время реакции. Допустимая задержка для таких приложений составляет от 100 до 200 миллисекунд.

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

· Приложения реального времени. Хотя система UNIX изначально раз­рабатывалась как операционная система разделения времени, ряд приложений требуют дополнительных системных возможностей, в частности, гарантированного времени совершения той или иной операции, времени отклика и т. п. Примером могут служить измерительные комплексы или системы управления. Видеоприложения также могут обладать определенными ограничениями на время обра­ботки кадра изображения.

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

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

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

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

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

Каждый процесс имеет два атрибута приоритета: текущий приоритет, на основании которого происходит планирование, и заказанный относитель­ный приоритет, называемый nice number (или просто nice), который зада­ется при порождении процесса и влияет на текущий приоритет.

Текущий приоритет варьируется в диапазоне от 0 (низкий приоритет) до 127 (наивысший приоритет). Процессы, выполняющиеся в режиме задачи, имеют более низкий приоритет, чем в режиме ядра. Для режима задачи приоритет меняется в диапазоне 0-65, для режима ядра - 66-95 (систем­ный диапазон).

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

Процессу, ожидающему недоступного в данный момент ресурса, система определяет значение приоритета сна, выбираемое ядром из диапазона сис­темных приоритетов и связанное с событием, вызвавшее это состояние. В табл. 3.3 приведены значения приоритетов сна для систем 4.3BSD UNIX и SCO UNIX (OpenServer 5.0). Заметим, что направление роста значений приоритета для этих систем различно - в BSD UNIX большему значению соответствует более низкий приоритет.

Событие Приоритет 4.3BSD UNIX Приоритет SCO UNIX
Ожидание загрузки в память сегмен­та/страницы (свопинг/страничное замещение)
Ожидание индексного дескриптора
Ожидание ввода/вывода
Ожидание буфера
Ожидание терминального ввода  
Ожидание терминального вывода  
Ожидание завершения выполнения  
Ожидание события - низкоприоритетное со­стояние сна

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

После завершения системного вызова перед возвращением в режим задачи ядро восстанавливает приоритет режима задачи, сохраненный перед вы­полнением системного вызова. Это может привести к понижению приори­тета, что, в свою очередь, вызовет переключение контекста.

Текущий приоритет процесса в режиме задачи p_priuser зависит от двух факторов: значения nice number и степени использования вычислительных ресурсов р_cpu:

p_priuser = a*p_nice - b*p_cpu,

где p_nice - постоянная составляющая, зависящая от параметра nice.

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

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

Например, UNIX версии SVR3, использует следующую формулу:

p_cpu = p_cpu/2

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

В 4.3BSD UNIX для пересчета р_сри используется другая формула:

p_cpu = p_cpu*(2*load)/(2*load+l)

Здесь параметр load равен среднему числу процессов, находившихся в очереди на выполнение за последнюю секунду, и характеризует среднюю загрузку системы за этот период времени. Этот алгоритм позволяет час­тично избавиться от недостатка планирования SVR3, поскольку при зна­чительной загрузке системы уменьшение р_сри при пересчете будет про­исходить медленнее.

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

Как правило, очередь на выполнение не одна. Например, SCO UNIX име­ет 127 очередей - по одной на каждый приоритет. BSD UNIX использует 32 очереди, каждая из которых обслуживает диапазон приоритетов, на­пример 0-3, 4-7 и т. д. При выборе следующего процесса на выполнение из одной очереди, т. е. из нескольких процессов с одинаковым текущим приоритетом, используется механизм кругового чередования (round robin). Этот механизм запускается ядром через каждый временной квант для наи­более приоритетной очереди. Однако если в системе появляется готовый к запуску процесс с более высоким приоритетом, чем текущий, он будет за­пущен, не дожидаясь прошествия временного кванта. С другой стороны, если все процессы, готовые к запуску, находятся в низкоприоритетных по отношению к текущему процессу очередях, последний будет продолжать выполняться и в течение следующего временного кванта.