Операционные системы. Учебное пособие. Марапулец Ю.В. - 53 стр.

UptoLike

Составители: 

планироваться на выполнение. Эта задача снимет с выполнения текущее приложение,
оно будет поставлено в конец очереди, и поскольку этой высокоприоритетной задаче на
самом деле ничего делать не надо, то она тут же освободит процессор и из очереди го-
товности будет взята следующая задача.
Рассмотренные дисциплины диспетчеризации процессов могут быть разбиты на
два класса - вытесняющие (preemptive) и не вытесняющие (non preemptive) [5]. В
большинстве современных ОС для мощных вычислительных систем, а также и в ОС для
ПК, ориентированных на высокопроизводительное выполнение приложений (Windows
NT, OS/2, Linux), реализована вытесняющая многозадачность.
Диспетчеризация без перераспределения процессорного времени называется не
вытесняющая многозадачность (non-preemptive multitasking). Это такой способ дис-
петчеризации процессов, при котором активный процесс выполняется до тех пор, пока
он сам, что называется «по собственной инициативе», не отдаст управление диспетчеру
задач для выбора из очереди другого, готового к выполнению процесса или потока.
Дисциплины обслуживания FCFS, SJN, SRT относятся к не вытесняющим.
Диспетчеризация с перераспределением процессорного времени между задачами
называется вытесняющая многозадачность (preemptive multitasking). Это такой спо-
соб, при котором решение о переключении процессора с выполнения одного процесса на
выполнение другого процесса принимается диспетчером задач, а не самой активной за-
дачей. При вытесняющей многозадачности механизм диспетчеризации задач целиком
сосредоточен в операционной системе, и программист может писать свое приложение,
не заботясь о том, как оно будет выполняться параллельно с другими задачами. При
этом операционная система выполняет следующие функции: определяет момент снятия
с выполнения текущей задачи, сохраняет ее контекст в дескрипторе задачи, выбирает из
очереди готовых задач следующую и запускает ее на выполнение, предварительно за-
грузив ее контекст. Дисциплина RR и многие другие, построенные на ее основе, отно-
сятся к вытесняющим.
Одна из проблем, которая возникает при выборе подходящей дисциплины обслу-
живания, - это гарантия обслуживания. Дело в том, что при некоторых дисциплинах, на-
пример при использовании дисциплины абсолютных приоритетов, низкоприоритетные
процессы оказываются обделенными многими ресурсами и, прежде всего, процессор-
ным временем. Возникает реальная дискриминация низкоприоритетных задач, и ряд та-
ких процессов, имеющих к тому же большие потребности в ресурсах, могут очень дли-
тельное время откладываться или, в конце концов, вообще могут быть не выполнены.
Поэтому вопрос гарантии обслуживания является очень актуальным. Существуют раз-
личные дисциплины диспетчеризации, учитывающие жесткие временные ограничения,
но не существует дисциплин, которые могли бы предоставить больше процессорного
времени, чем может быть в принципе выделено.
Планирование с учетом жестких временных ограничений легко реализовать, орга-
низуя очередь готовых к выполнению процессов в порядке возрастания их временных
ограничений. Основным недостатком такого простого упорядочения является то, что
процесс (за счет других процессов) может быть обслужен быстрее, чем это ему реально
необходимо. Для того чтобы избежать этого, проще всего процессорное время выделять
все-таки квантами. С учетом сказанного выше гарантировать обслуживание можно
следующими тремя способами [2]:
выделять минимальную долю процессорного времени некоторому классу процессов,
если по крайней мере один из них готов к исполнению. Например, можно отводить
20 % от каждых 10 мс процессам реального времени, 40 % от каждых 2 сек - инте-
рактивным процессам и 10 % от каждых 5 мин - фоновым процессам;
выделять минимальную долю процессорного времени некоторому конкретному
процессу, если он готов к выполнению;
55
планироваться на выполнение. Эта задача снимет с выполнения текущее приложение,
оно будет поставлено в конец очереди, и поскольку этой высокоприоритетной задаче на
самом деле ничего делать не надо, то она тут же освободит процессор и из очереди го-
товности будет взята следующая задача.
      Рассмотренные дисциплины диспетчеризации процессов могут быть разбиты на
два класса - вытесняющие (preemptive) и не вытесняющие (non preemptive) [5]. В
большинстве современных ОС для мощных вычислительных систем, а также и в ОС для
ПК, ориентированных на высокопроизводительное выполнение приложений (Windows
NT, OS/2, Linux), реализована вытесняющая многозадачность.
      Диспетчеризация без перераспределения процессорного времени называется не
вытесняющая многозадачность (non-preemptive multitasking). Это такой способ дис-
петчеризации процессов, при котором активный процесс выполняется до тех пор, пока
он сам, что называется «по собственной инициативе», не отдаст управление диспетчеру
задач для выбора из очереди другого, готового к выполнению процесса или потока.
Дисциплины обслуживания FCFS, SJN, SRT относятся к не вытесняющим.
      Диспетчеризация с перераспределением процессорного времени между задачами
называется вытесняющая многозадачность (preemptive multitasking). Это такой спо-
соб, при котором решение о переключении процессора с выполнения одного процесса на
выполнение другого процесса принимается диспетчером задач, а не самой активной за-
дачей. При вытесняющей многозадачности механизм диспетчеризации задач целиком
сосредоточен в операционной системе, и программист может писать свое приложение,
не заботясь о том, как оно будет выполняться параллельно с другими задачами. При
этом операционная система выполняет следующие функции: определяет момент снятия
с выполнения текущей задачи, сохраняет ее контекст в дескрипторе задачи, выбирает из
очереди готовых задач следующую и запускает ее на выполнение, предварительно за-
грузив ее контекст. Дисциплина RR и многие другие, построенные на ее основе, отно-
сятся к вытесняющим.
      Одна из проблем, которая возникает при выборе подходящей дисциплины обслу-
живания, - это гарантия обслуживания. Дело в том, что при некоторых дисциплинах, на-
пример при использовании дисциплины абсолютных приоритетов, низкоприоритетные
процессы оказываются обделенными многими ресурсами и, прежде всего, процессор-
ным временем. Возникает реальная дискриминация низкоприоритетных задач, и ряд та-
ких процессов, имеющих к тому же большие потребности в ресурсах, могут очень дли-
тельное время откладываться или, в конце концов, вообще могут быть не выполнены.
Поэтому вопрос гарантии обслуживания является очень актуальным. Существуют раз-
личные дисциплины диспетчеризации, учитывающие жесткие временные ограничения,
но не существует дисциплин, которые могли бы предоставить больше процессорного
времени, чем может быть в принципе выделено.
      Планирование с учетом жестких временных ограничений легко реализовать, орга-
низуя очередь готовых к выполнению процессов в порядке возрастания их временных
ограничений. Основным недостатком такого простого упорядочения является то, что
процесс (за счет других процессов) может быть обслужен быстрее, чем это ему реально
необходимо. Для того чтобы избежать этого, проще всего процессорное время выделять
все-таки квантами. С учетом сказанного выше гарантировать обслуживание можно
следующими тремя способами [2]:
• выделять минимальную долю процессорного времени некоторому классу процессов,
    если по крайней мере один из них готов к исполнению. Например, можно отводить
    20 % от каждых 10 мс процессам реального времени, 40 % от каждых 2 сек - инте-
    рактивным процессам и 10 % от каждых 5 мин - фоновым процессам;
• выделять минимальную долю процессорного времени некоторому конкретному
    процессу, если он готов к выполнению;

                                        55