Процессы в операционной системе UNIX играют ключевую роль. От оптимальной настройки подсистемы управления процессами и числа одновременно выполняющихся процессов зависит загрузка ресурсов процессора, что в свою очередь имеет непосредственное влияние на производительность системы в целом. Ядро операционной системы предоставляет задачам базовый набор услуг, определяемый интерфейсом системных вызовов. К ним относятся основные операции по работе с файлами, управление процессами и памятью, поддержка межпроцессного взаимодействия. Дополнительные функциональные возможности системы, т. е. услуги, которые она предоставляет пользователям, определяются активными процессами. От того, какие процессы выполняются в вашей системе, зависит, является ли она сервером базы данных или сервером сетевого доступа, средством проектирования или вычислительным сервером. Даже так называемые уровни выполнения системы (run levels), которые мы рассмотрим позже, представляют собой удобный способ определения группы выполняющихся процессов и, соответственно, функциональности системы.
Обычно программой называют совокупность файлов, будь то набор исходных текстов, объектных файлов или собственно выполняемый файл. Для того чтобы программа могла быть запущена на выполнение, операционная (система сначала должна создать окружение или среду выполнения задачи, куда относятся ресурсы памяти, возможность доступа к устройствам ввода/вывода и различным системным ресурсам, включая услуги ядра.
Это окружение (среда выполнения задачи) получило название процесса. Мы можем представить процесс как совокупность данных ядра системы, необходимых для описания образа программы в памяти и управления ее выполнением. Мы можем также представить процесс как программу в стадии ее выполнения, поскольку все выполняющиеся программы представлены в UNIX в виде процессов. Процесс состоит из инструкций, выполняемых процессором, данных и информации о выполняемой задаче, такой как размещенная память, открытые файлы и статус процесса.
В то же время не следует отождествлять процесс с программой хотя бы потому, что программа может породить более одного процесса. Простейшие программы, например, команда who(l) или cat(l), при выполнении представлены только одним процессом. Сложные задачи, например системные серверы (печати, FTP, Telnet), порождают в системе несколько одновременно выполняющихся процессов.
Операционная система UNIX является многозадачной. Это значит, что одновременно может выполняться несколько процессов, причем часть процессов могут являться образцами одной программы.
Выполнение процесса заключается в точном следовании набору инструкций, который никогда не передает управление набору инструкций другого процесса. Процесс считывает и записывает информацию в раздел данных и в стек, но ему недоступны данные и стеки других процессов.
В то же время процессы имеют возможность обмениваться друг с другом данными с помощью предоставляемой UNIX системой межпроцессного взаимодействия. В UNIX существует набор средств взаимодействия между процессами, таких как сигналы (signals), каналы (pipes), разделяемая память (shared memory), семафоры (semaphores), сообщения (messages) и файлы, но в остальном процессы изолированы друг от друга.
Системные процессы. Системные процессы являются частью ядра и всегда расположены в оперативной памяти. Системные процессы не имеют соответствующих им программ в виде исполняемых файлов и запускаются особым образом при инициализации ядра системы. Выполняемые инструкции и данные этих процессов находятся в ядре системы, таким образом они могут вызывать функции и обращаться к данным, недоступным для остальных процессов. Системными процессами являются: shed (диспетчер свопинга), vhand (диспетчер страничного замещения), bdfflush (диспетчер буферного кэша) и kmadaemon (диспетчер памяти ядра). К системным процессам следует отнести init, являющийся прародителем всех остальных процессов в UNIX. Хотя init не является частью ядра, и его запуск происходит из исполняемого файла (/etc/init), его работа жизненно важна для функционирования всей системы в целом.
Демоны. Демоны — это неинтерактивные процессы, которые запускаются обычным образом — путем загрузки в память соответствующих им программ (исполняемых файлов), и выполняются в фоновом режиме. Обычно демоны запускаются при инициализации системы (но после инициализации ядра,) и обеспечивают работу различных подсистем UNIX: системы терминального доступа, системы печати, системы сетевого доступа и сетевых услуг и т. п. Демоны не связаны ни с одним пользовательским сеансом работы и не могут непосредственно управляться пользователем. Большую часть времени демоны ожидают пока тот или иной процесс запросит определенную услугу, например, доступ к файловому архиву или печать документа.
Прикладные процессы. К прикладным процессам относятся все остальные процессы, выполняющиеся в системе. Как правило, это процессы, порожденные в рамках пользовательского сеанса работы. С такими процессами вы будете сталкиваться чаще всего. Например, запуск команды ls(l) породит соответствующий процесс этого типа. Важнейшим пользовательским процессом является основной командный интерпретатор (login shell), который обеспечивает вашу работу в UNIX. Он запускается сразу же после вашей регистрации в системе, а завершение работы login shell приводит к отключению от системы.
Пользовательские процессы могут выполняться как в интерактивном, так и в фоновом режиме, но в любом случае время их жизни (и выполнения) ограничено сеансом работы пользователя. При выходе из системы все пользовательские процессы будут уничтожены.
Интерактивные процессы монопольно владеют терминалом, и пока такой процесс не завершит свое выполнение, пользователь не сможет работать другими приложениями.
Вы сможете работать с другими приложениями, если в функции интерактивного процесса входит запуск на выполнение других программ. Примером такой задачи является командный интерпретатор shell, который считывает пользовательский ввод и запускает соответствующие задачи.
Процесс в UNIX имеет несколько атрибутов, позволяющих операционной системе эффективно управлять его работой, важнейшие из которых рассмотрены ниже.
- Идентификатор процесса Process ID (PID). Каждый процесс имеет уникальный идентификатор PID, позволяющий ядру системы различать процессы. Когда создается новый процесс, ядро присваивает ему следующий свободный (т. е. не ассоциированный ни с каким процессом) идентификатор. Присвоение идентификаторов происходит по возрастающий, т. е. идентификатор нового процесса больше, чем идентификатор процесса, созданного перед ним. Если идентификатор достиг максимального значения, следующий процесс получит минимальный свободный PID и цикл повторяется. Когда процесс завершает свою работу, ядро освобождает занятый им идентификатор.
- Идентификатор родительского процесса Parent Process ID (PPID). Идентификатор процесса, породившего данный процесс.
- Приоритет процесса (Nice Number).Относительный приоритет процесса, учитываемый планировщиком при определении очередности запуска. Фактическое же распределение процессорных ресурсов определяется приоритетом выполнения, зависящим от нескольких факторов, в частности от заданного относительного приоритета. Относительный приоритет не изменяется системой на всем протяжении жизни процесса (хотя может быть изменен пользователем или администратором) в отличие от приоритета выполнения, динамически обновляемого ядром.
- Терминальная линия (TTY). Терминал или псевдотерминал, ассоциированный с процессом, если такой существует. Процессы-демоны не имеют ассоциированного терминала.
- Реальный (RID) и эффективный (EUID) идентификаторы пользователя. Реальным идентификатором пользователя данного процесса является идентификатор пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа процесса к системным ресурсам (в первую очередь к ресурсам файловой системы). Обычно реальный и эффективный идентификаторы эквивалентны, т. е. процесс имеет в системе те же права, что и пользователь, запустивший его. Однако существует возможность задать процессу более широкие права, чем права пользователя путем установки флага SUID, когда эффективному идентификатору присваивается значение идентификатора владельца исполняемого файла (например, администратора).
- Реальный (RGID) и эффективный (EGID) идентификаторы группы. Реальный идентификатор группы равен идентификатору первичной или текущей группы пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа к системным ресурсам по классу доступа группы. Так же как и для эффективного идентификатора пользователя, возможна его установка равным идентификатору группы владельца исполняемого файла (флаг SGID).
Команда ps(1) (process status) позволяет вывести список процессов, выполняющихся в системе, и их атрибуты:
|
$ ps
|
-ef
|
head –20
| ||||||
|
UID
|
PID
|
PPID
|
С
|
STIME
|
TTY
|
TIME
| ||
|
root |
0 |
0 |
0 |
Dec |
17 |
7 |
0 |
00 |
|
root |
1 |
0 |
0 |
Dec |
17 |
7 |
0 |
01 |
|
root |
2 |
0 |
0 |
Dec |
17 |
7 |
0 |
00 |
|
root |
3 |
0 |
0 |
Dec |
17 |
7 |
7 |
00 |
|
root |
164 |
1 |
0 |
Dec |
17 |
7 |
0 |
01 |
|
fed |
627 |
311 |
0 |
Dec |
17 |
pts/3 |
0 |
27 |
|
fed |
314 |
304 |
0 |
Dec |
17 |
pts/4 |
0 |
00 |
|
fed
|
3521
|
512
|
0
|
|
|
|
0
|
01
|
При регистрации пользователя в системе утилита login(l) запускает командный интерпретатор, — login shell, имя которого является одним из атрибутов пользователя. При этом идентификаторам DID (EUID) и GID KEGID процесса shell присваиваются значения, полученные из записи Пользователя в файле паролей /etc/passwd. Таким образом, командный интерпретатор обладает правами, определенными для данного пользователя.
При запуске программы командный интерпретатор порождает процесс, который наследует все четыре идентификатора и, следовательно, имеет те же права, что и shell. Поскольку в конкретном сеансе работы пользователя в системе прародителем всех процессов является login shell, то и их пользовательские идентификаторы будут идентичны.
Казалось бы, эту стройную систему могут "испортить" утилиты с установленными флагами SUID и SGID. Но не стоит волноваться — как правило, такие программы не позволяют порождать другие процессы, в противном случае, эти утилиты необходимо немедленно уничтожить!
Рисунок 4.1 – процесс наследования процессов
На рис. 4.1 показан процесс наследования пользовательских идентификаторов в рамках одного сеанса работы.Для получения значений идентификаторов процесса используются следующие системные вызовы:
ftinclude <sys/types.h> ftinclude <unistd.h> uid t getuid(void);
uid_t geteuid(void);
gid t getgid(void);
gid_t getegid(void);
Эти функции возвращают для сделавшего вызов процесса соответственно реальный и эффективный идентификаторы пользователя и реальный и эффективный идентификаторы группы.
Процесс также может изменить значения этих идентификаторов с помошью системных вызовов:
#include <sys/types.h>
#include <unistd.h> int setuid(uid_t uid);
int setegid(gid_t egid);
int seteuid(uid_t euid) ;
int setgid(gid_t gid);
Системные вызовы setuid(2) и setgid(2) устанавливают сразу реальный и эффективный идентификаторы, а системные вызовы seteuid(2) и setegid(2) — только эффективные.
Жизненный путь процесса
Работая в командной строке shell вы, возможно, не задумывались, каким образом запускаются программы. На самом деле каждый раз порождается новый процесс, а затем загружается программа. В UNIX эти два этапа четко разделены. Соответственно система предоставляет два различных системных вызова: один для создания процесса, а другой для запуска новой программы.
Новый процесс в UNIX порождается с помощью системного вызова fork(2):
#include <sys/types.h>
#include <unistd.h>
pid_t fork (void);
Процесс, сделавший вызов fork(2) называется родительским, а вновь созданный процесс — дочерним. Новый процесс является точной копией породившего его процесса. Как это ни удивительно, но новый процесс имеет те же инструкции и данные, что и его родитель. Более того, выполнение родительского и дочернего процесса начнется с одной и той же инструкции, следующей за вызовом fork(2). Единственно, чем они различаются — это идентификатором процесса PID. Каждый процесс имеет одного родителя, но может иметь несколько дочерних процессов.
Порожденный, или дочерний процесс, хотя это кажется странным, является точной копией процесса, выполнившего этот вызов, или родительского процесса. В частности, дочерний процесс наследует такие атрибуты родителя, как:
- идентификаторы пользователя и группы
- переменные окружения,
- диспозицию сигналов и их обработчики,
- ограничения, накладываемые на процесс,
- текущий и корневой каталог,
- маску создания файлов,
- все файловые дескрипторы, включая файловые указатели,
- управляющий терминал.
Более того, виртуальная память дочернего процесса не отличается от образа родительского: такие же сегменты кода, данных, стека, разделяемой памяти и т. д. После возврата из вызова fork(2), который происходит и в родительский и в дочерний процессы, оба начинают выполнять одну и ту же инструкцию.
Легче перечислить немногочисленные различия между этими процессами, а именно:
- дочернему процессу присваивается уникальный идентификатор PID,
- идентификаторы родительского процесса PPID у этих процессов различны,
- дочерний процесс свободен от сигналов, ожидающих доставки
- значение, возвращаемое системным вызовом fork(2) различно для родителя и потомка.
Последнее замечание требует объяснения. Как уже говорилось, возврат из функции fork(2) происходит как в родительский, так и в дочерний процесс. При этом возвращаемое родителю значение равно PID дочернего процесса, а дочерний, в свою очередь, получает значение, равное 0.
Если fork(2) возвращает -1, то это свидетельствует об ошибке (естественно, в этом случае возврат происходит только в процесс, выполнивший системный вызов).
В возвращаемом fork(2) значении заложен большой смысл, поскольку оно позволяет определить, кто является родителем, а кто — потомком, и соответственно разделить функциональность. Поясним это на примере:
main() {
int pid;
pid = fork ();
if (pid == -1)
{ perror("fork"); exit(l);}
if (pid ==0) printf("ПОTOMOK\n");
else printf("Родитель\п");
}
Таким образом, порождение нового процесса уже не кажется абсолютно бессмысленным, поскольку родитель и потомок могут параллельно выполнять различные функции. В данном случае, это вывод на терминал различных сообщений, однако можно представить себе и более сложные приложения. В частности, большинство серверов, одновременно обслуживающих несколько запросов, организованы именно таким образом: при поступлении запроса порождается процесс, который и выполняет необходимую обработку. Родительский процесс является своего рода супервизором, принимающим запросы и распределяющим их выполнение. Очевидным недостатком такого подхода является то, что вся функциональное по-прежнему заложена в одном исполняемом файле и, таким образом, ограничена.
Для запуска задачи, т. е. для загрузки новой программы, процесс должен выполнить системный вызов ехес(2). При этом новый процесс не порождается, а исполняемый код процесса полностью замещается кодом запускаемой программы. Тем не менее окружение новой программы во многом сохраняется, в частности сохраняются значения переменных окружения, назначения стандартных потоков ввода/вывода, вывода сообщений об ошибках, а также приоритет процесса.
#include <unistd.h>
int execl(const char *path, const char *arg0, ..., const char *argn, char * /*NULL*/);
int execv(const char *path, char *const argv[]);
int execle (const char *path,char *const arg0[], ... ,const char *argn, char * /*NULL*/, char *const envp[]);
int execve (const char *path, char *const argv[], char *const envp[]);
int execlp (const char *file, const char *arg0, ...,const char *argn, char * /*NULL*/);
int execvp (const char *file, char *const argv[]);
Все эти функции по существу являются надстройками системного вызова execve(2), который в качестве аргументов получает имя запускаемой программы (исполняемого файла), набор аргументов и список переменных окружения. После выполнения execve(2) не создается новый процесс, а образ существующего полностью заменяется на образ, полученный из указанного исполняемого файла. На рис. 2.12 показано, как связаны между собой приведенные выше функции.
-
Рисунок 4.2
В отличие от вызова fork(2), новая программа наследует меньше атрибутом В частности, наследуются:
- идентификаторы процесса PID и PPID,
- идентификаторы пользователя и группы,
- эффективные идентификаторы пользователя и группы (в случае если для исполняемого файла не установлен флаг SUID или SGID).
- ограничения, накладываемые на процесс,
- текущий и корневой каталоги,
- маска создания файлов,
- файловые дескрипторы, для которых не установлен флаг FD_CLOEXEC,
управляющий терминал.
Наследование характеристик процесса играет существенную роль в работе операционной системы. Так наследование идентификаторов владельцев процесса гарантирует преемственность привилегий и, таким образом, неизменность привилегий пользователя при работе в UNIX. Наследование файловых дискрипторов позволяет установить направления ввода/вывода для нового процесса или новой программы. Именно так действует командный интерпретатор.
Путем объединенного вызова fork(2) и ехес(2), получившем специальное название fork-and-exec загружается подавляющее большинство программ, которые выполняются в системе.
Рассмотрим эту схему на примере.
Допустим, пользователь, работая в командном режиме (в командном интерпретаторе shell) запускает команду ls(l). Текущий процесс (shell) делает вызов fork(2), порождая вторую копию shell. В свою очередь, порожденный shell вызывает ехес(2), указывая в качестве параметра имя исполняемого файла, образ которого необходимо загрузить в память вместо кода shell. Код ls(l) замещает код порожденного shell, и утилита ls(l) начинает выполняться. По завершении работы ls(l) созданный процесс "умирает". (Пользователь вновь возвращается в командный режим. Описанный процесс представлен на рис. 1.5
. 
Рисунок 4.3 Создание процесса и запуск программы
Если сделать "отпечаток" выполняемых процессов, например командой Ps(I}, между указанными стадиями, результат был бы следующим:
Пользователь работает в командном режиме:
uid useri
PID 745
PPID 1
CMD sh
Пользователь запустил команду ls(l), и shell произвел вызов fork(2):
UID useri useri
PID 745 802
PPID 1 745
CMD sh sh
Порожденный shell произвел вызов ехес(2):
UID useri useri
PID 745 802
PPID 1 745
CMD sh Is
Процесс ls(l) завершил работу:
UID useri
PID 745
PPID 1
CMD sh
Описанная процедура запуска новой программы называется fork-and-exec.
Однако бывают ситуации, когда достаточно одного вызова fork(2) без последующего ехвс(2). В этом случае исполняемый код родительского процесса должен содержать логическое ветвление для родительского и дочернего процессов.
Все процессы в UNIX создаются посредством вызова fork(2). Запуск на выполнение новых задач осуществляется либо по схеме fork-and-exec, либо с помощью ехес(2). "Прародителем" всех процессов является процесс init(lM), называемый также распределителем процессов. Если построить граф "родственных отношений" между процессами, то получится дерево, корнем которого является init(lM). Показанные на рис. 1.6 процессы sched и vhand являются системными и формально не входят в иерархию.
Рис. 1.6. Типичное "дерево" процессов в UNIX Для отправления сигнала служит команда kill(l):
Контекст
процесса складывается из пользовательского контекста и контекста ядра, как
изображено на рисунке:
Под пользовательским контекстом процесса понимают код и данные,
расположенные в адресном пространстве процесса. Все данные подразделяются на
инициализируемые неизменяемые данные (например, константы), инициализируемые
изменяемые данные (все переменные, начальные значения которых присваиваются на
этапе компиляции), неинициализируемые изменяемые данные (все статические
переменные, которым не присвоены начальные значения на этапе компиляции), стек
пользователя и данные, расположенные в динамически выделяемой памяти (например,
с помощью стандартных библиотечных C функций malloc, calloc и realloc).
Исполняемый код и инициализируемые данные составляют содержимое файла
программы, который исполняется в контексте процесса. Пользовательский стек
используется при работе процесса в пользовательском режиме
(user-mode).
Под понятием
контекст ядра объединяются системный контекст и регистровый контекст,
рассмотренные на лекции. Мы будем выделять в контексте ядра стек ядра, который
используется при работе процесса в режиме ядра (kernel mode), и данные
ядра, хранящиеся в структурах, являющихся аналогом блока управления процессом -
PCB. Состав данных ядра будет уточняться на последующих семинарах. На этом
занятии нам достаточно знать, что в данные ядра входят: идентификатор
пользователя - UID, групповой идентификатор пользователя - GID, идентификатор
процесса - PID, идентификатор родительского процесса - PPID.
Краткая
диаграмма состояний процессов в операционной системе UNIX изображена на рисунке:
Как видим, состояние процесса исполнение
расщепилось на 2 состояния: исполнение в режиме ядра и
исполнение в режиме пользователя. В состоянии исполнение в
режиме пользователя процесс выполняет прикладные инструкции
пользователя. В состоянии исполнение в режиме ядра
выполняются инструкции ядра операционной системы в контексте текущего процесса
(например, при обработке системного вызова или прерывания). Из состояния
исполнение в режиме пользователя процесс не может непосредственно
перейти в состояния ожидание, готовность и
закончил исполнение. Такие переходы возможны только через
промежуточное состояние исполняется в режиме ядра. Точно также
запрещен прямой переход из состояния готовность в состояние
исполнение в режиме пользователя.
Приведенная
выше диаграмма состояний процессов в Linux не является полной. Она показывает
только состояния, для понимания которых достаточно уже полученных знаний. Полную
диаграмму состояний процессов в операционной системе UNIX можно найти в книге
Баха "Архитектура операционной системы UNIX" (рисунок 6.1.).
В системе UNIX System V Release 4 реализована вытесняющая многозадачность, основанная на использовании приоритетов и квантования.
Все процессы разбиты на несколько групп, называемых классами приоритетов. Каждая группа имеет свои характеристики планирования процессов.
Созданный процесс наследует характеристики планирования процесса-родителя, которые включают класс приоритета и величину приоритета в этом классе. Процесс остается в данном классе до тех пор, пока не будет выполнен системный вызов, изменяющий его класс.
В UNIX System V Release 4 возможно включение новых классов приоритетов при инсталляции системы. В настоящее время имеется три приоритетных класса: класс реального времени, класс системных процессов и класс процессов разделения времени. В отличие от ранних версий UNIX приоритетность (привилегии) процесса тем выше, чем больше число, выражающее приоритет. На рисунке 5.2 показаны диапазоны изменения приоритетов для разных классов. Значения приоритетов определяются для разных классов по разному.
Процессы системного класса используют стратегию фиксированных приоритетов. Системный класс зарезервирован для процессов ядра. Уровень приоритета процессу назначается ядром и никогда не изменяется. Заметим, что пользовательский процесс, перешедший в системную фазу, не переходит при этом в системный класс приоритетов.
Процессы реального времени также используют стратегию фиксированных приоритетов, но пользователь может их изменять. Так как при наличии готовых к выполнению процессов реального времени другие процессы не рассматриваются, то процессы реального времени надо тщательно проектировать, чтобы они не захватывали процессор на слишком долгое время. Характеристики планирования процессов реального времени включают две величины: уровень глобального приоритета и квант времени. Для каждого уровня приоритета имеется по умолчанию своя величина кванта времени. Процессу разрешается захватывать процессор на указанный квант времени, а по его истечении планировщик снимает процесс с выполнения.
|
Приоритетный класс |
Выбор |
Глобальное значение |
|
Реальное время (real time) |
первый |
159 100 |
|
Системные |
… |
99 60 |
|
Процессы |
… |
59 0 |
|
Возможно добавление новых классов |
||
Рис. 5.2. Приоритетные классы процессов
Процессы разделения времени были до появления UNIX System V Release 4 единственным классом процессов, и по умолчанию UNIX System V Release 4 назначает новому процессу этот класс. Состав класса процессов разделения времени наиболее неопределенный и часто меняющийся, в отличие от системных процессов и процессов реального времени. Для справедливого распределения времени процессора между процессами, в этом классе используется стратегия динамических приоритетов, которая адаптируется к операционным характеристикам процесса.
Величина приоритета, назначаемого процессам разделения времени, вычисляется пропорционально значениям двух составляющих: пользовательской части и системной части. Пользовательская часть приоритета может быть изменена суперпользователем и владельцем процесса, но в последнем случае только в сторону его снижения.
Системная составляющая позволяет планировщику управлять процессами в зависимости от того, как долго они используют процессор, не уходя в состояние ожидания. Тем процессам, которые потребляют большие периоды времени без ухода в состояние ожидания, приоритет снижается, а тем процессам, которые часто уходят в состояние ожидания после короткого периода использования процессора, приоритет повышается. Таким образом, процессам, ведущим себя не по-джентльменски, дается низкий приоритет, что означает, что они реже выбираются на выполнение. Но процессам с низким приоритетом даются большие кванты времени, чем процессам с высокими приоритетами. Таким образом, хотя низкоприоритетный процесс и не работает так часто, как высокоприоритетный, но зато, когда он наконец выбирается на выполнение, ему отводится больше времени.
Планировщик использует следующие характеристики для процессов разделения времени:
|
ts_globpri |
содержит величину глобального приоритета; |
|
ts_quantum |
определяет количество тиков системных часов, которые отводятся процессу до его вытеснения; |
|
ts_tqexp |
системная часть приоритета, назначаемая процессу при истечении его кванта времени; |
|
ts_slpret |
системная составляющая приоритета, назначаемая процессу после выхода его из состояния ожидания; ожидающим процессам дается высокий приоритет, так что они быстро получают доступ к процессору после освобождения ресурса; |
|
ts_maxwaite |
максимальное число секунд, которое разрешается потреблять процессу; если этот квант времени истекает до кванта ts_quantum, то, следовательно, считается, что процесс ведет себя по-джентльменски, и ему назначается более высокий приоритет; |
|
ts_lwait |
величина системной части приоритета, назначаемая процессу, если истекает ts_maxwait секунд. |
Для процессов разделения времени в дескрипторе процесса proc имеется указатель на структуру, специфическую для данного класса процесса. Эта структура состоит из полей, используемых для вычисления глобального приоритета:
|
ts_timeleft |
число тиков, остающихся в кванте процесса; |
|
ts_cpupri |
системная часть приоритета процесса; |
|
ts_uprilim, ts_upri |
верхний предел и текущее значение пользовательской части приоритета. Эти две переменные могут модифицироваться пользователем; |
|
ts_nice |
используется для обратной совместимости с системным вызовом nice. Она содержит текущее значение величины nice, которая влияет на результирующую величину приоритета. Чем выше эта величина, тем меньше приоритет. |
В версии SVR4 нет поддержки многонитевой (multithreading) организации процессов на уровне ядра, хотя и есть два системных вызова для организации нитей в пользовательском режиме. Во многих коммерческих реализациях UNIX, базирующихся на кодах SVR4, в ядро включена поддержка нитей за счет собственной модификации исходных текстов SVR4.
|
|
 |
