Пример работы:

Поток 2 удерживает ресурс, поток 1 ждёт его.

Поток 2 наследует приоритет потока 1 (становится выше, чем у потока 3). Поток 2 завершает критический раздел, освобождает ресурс.

Поток 1 захватывает ресурс и выполняется.

Поток 2 возвращается к своему низкому приоритету, и поток 3 получает процессор, если нет других задач с более высоким приоритетом.

29. Алгоритмы планирования Linux: О(1)

Планировщик O(1) (Linux 2.6 до 2.6.23) обеспечивает операции планирования за постоянное время (O(1)) для многопроцессорных систем и интерактивных задач.

Ключевые особенности:

●​ Структура: Для каждого CPU — активная и истёкшая очереди, организованные как массивы приоритетов (0–99 для реального времени, 100–139 для обычных задач).

●​ Кванты времени: Высокоприоритетные задачи получают большие кванты.

●​ Динамический приоритет: Переменная sleep_avg корректирует приоритет (±5) на основе времени ожидания (увеличивается при «сне», уменьшается при выполнении).

●​ Работа: Выбирает задачу с наивысшим приоритетом из активной очереди. После истечения кванта задача перемещается в истёкшую очередь, при пустой активной очереди они меняются.

Преимущества: Быстрота, поддержка многопроцессорности, интерактивность через sleep_avg.

Недостатки: Сложность настройки, ограниченная гибкость при высоких нагрузках. Заменён на CFS с ядра 2.6.23.

Пример: Задача с приоритетом 100 получает квант 100 мс, с 120 — 10 мс. Интерактивные задачи повышают приоритет через sleep_avg (например, с 120 до 115),

что ускоряет её выполнение при пробуждении.

30. Алгоритмы планирования Linux: CFS

Вполне равномерный планировщик.

Цель планирования: равномерно распределить процессорное время между всеми конкурирующими процессами.

Для каждого процесса поддерживают значение vruntime (виртуальное время выполнения).

В CFS все runnable процессы хранятся в red-black дереве, которое отсортировано по vruntime процесса, что является количеством процессорного времени в наносекундах, которое процесс использовал. Таким образом получается, что в левой части дерева находятся процессы, которые использовали меньше всего времени, а в правой части те, что больше всего. И когда CFS выбирает, какой задаче дать доступ к процессорному времени, он выбирает самую левую задачу в дереве,

то-есть ту, которая получила его меньше всех.

Когда задача получает доступ к процессорному времени, она получает его на заранее предопределённый промежуток времени, называемый slice. Он может увеличиваться и уменьшаться в зависимости от NICE значения процесса.

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

максимальное +19.

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

​Несмотря на то, что CFS действительно хорошо справлялся с “честным” распределением времени процессора на все runnable процессы, у него были и серьёзные недостатки. Один из них это невозможность правильно работать с процессами, которые требуют время процессора, как можно скорее. Для того, чтобы подружить CFS с этой историей были внедрены так называемые latency nice патчи.

Они добавляли новое значение latency-nice, которое было зеркально существующему

nice значению, в том плане, что тоже имело ограничение от -20 до +19 и его понижение также, как и у nice, понижало толерантность к другим процессам. Если у нового процесса latency-nice был ниже, чем у того, который в текущее время работает в процессоре, то он мог заменить его. Таким образом задачи с низким latency-nice не получали больше процессорного времени, но получали право на его более быстрое выделение.

31. Планирование в ОС реального времени.

СМ ВОПРОС 27

32. Межпроцессное взаимодействие (почему необходимы системные средства и в каких ситуациях применяются, примеры таких средств).

IPC (Inter-Process Communication) — набор механизмов, позволяющих одновременно выполняющимся процессам обмениваться данными и синхронизировать свою работу.

•согласование действий процессов

•контроль над деятельностью процессов (Race Condition, Deadlock/Livelock, голодание, инверсия приоритетов …)

•передача информации от одного процесса другому

Почему необходимы системные средства?

1.​ Изоляция процессов: Каждый процесс имеет собственное адресное пространство, и прямой доступ к памяти другого процесса запрещён для предотвращения ошибок и уязвимостей.

2.​ Синхронизация: Процессы могут работать параллельно, и для предотвращения конфликтов (например, при доступе к общим ресурсам) нужны механизмы координации.

3.​ Обмен данными: Процессы часто должны передавать данные друг другу,

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

4.​ Надёжность и безопасность: Системные средства IPC предоставляются ОС, что гарантирует стандартизированный и безопасный способ взаимодействия.

Ситуации, в которых применяются IPC: ●​ Клиент-серверные приложения

●​ Многопроцессные приложения

●​ Параллельные вычисления ●​ Управление ресурсами

Примеры средств IPC:

●​ Мьютекс. Позволяет только одному иметь доступ к ресурсу.

●​ Семафоры. Управляют доступом к ресурсу. Могут быть бинарными (мьютекс) либо счетными.

●​ События. Нужны для уведомления одного или нескольких процессов о наступлении какого-либо события.

●​ Сигналы. Виртуальное прерывание, является сообщением, которое система посылает процессу или один процесс посылает другому.

Также рассмотрим средства для обмена данными:

●​ Канал (конвейер, pipe) – буфер в оперативной памяти, поддерживающий очередь байт по алгоритму FIFO.

●​ Очереди сообщений. Позволяют процессам обмениваться структурированными сообщениями.

●​ Сокеты. Обмен данными по сети или в пределах одной машины. ●​ Разделяемая память.

33. Синхронизация процессов и потоков: цели и средства синхронизации

Цели синхронизации:

Синхронизация процессов и потоков в мультипрограммных ОС необходима для:

●​ Исключения гонок и тупиков: Обеспечение корректного доступа к общим ресурсам (процессор, устройства ввода-вывода, данные).

●​ Координации взаимодействия: Согласование скоростей выполнения процессов/потоков для правильного обмена данными (например, ожидание данных в буфере).

●​ Управления ресурсами: Регулирование доступа к монопольным ресурсам, таким как порты или файлы.

●​ Реакции на события: Синхронизация с внешними или внутренними событиями

(например, нажатие клавиш или освобождение ресурса).

●​ Синхронизация требуется из-за асинхронного характера выполнения процессов в мультипрограммной среде, где время выполнения зависит от случайных

факторов: исходных данных, прерываний, очередей к ресурсам.

Средства синхронизации:

1.​ Семафоры:

Используются для управления доступом к общим ресурсам и предотвращения гонок.

Пример: POSIX-семафоры (sem_wait, sem_post) для ограничения доступа к файлу.

2.​ Мьютексы (Mutex):

Бинарные семафоры для монопольного доступа к ресурсу в многопоточной среде.

Пример: pthread_mutex_lock в POSIX для защиты критической секции.

3.​ Условные переменные:

Позволяют потокам ожидать определённого условия (например, поступления данных).