МИНОБРНАУКИ РОССИИ САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ЭЛЕКТРОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ «ЛЭТИ» ИМ. В.И. УЛЬЯНОВА (ЛЕНИНА) Кафедра «Информационные системы» РЕФЕРАТ № 3 по дисциплине «Системы реального времени» ТЕМА: СИНХРОНИЗАЦИЯ И ДИСПЕТЧЕРИЗАЦИЯ ЗАДАЧ Дата представления реферата на проверку: 19.02.2024 Студент гр. 0375 Пипоян Т.Г. tigranpipoyan@mail.ru Преподаватель Сидельников В.В. Санкт-Петербург 2024 СОДЕРЖАНИЕ 1. Понятие синхронизации задач, проблема тупиков и взаимного исключения, критическая секция .......................................................................... 3 2. Семафоры и мьютексы, монитор, условная переменная. ............................. 4 3. Проблема инверсии приоритетов, решения (протокол граничных приоритетов, протокол наследования приоритетов). .......................................... 7 4. Диспетчеризация задач, определение. .......................................................... 10 5. Состояние задачи, события, инициирующие смену состояния. ................ 11 6. Статические и динамические алгоритмы диспетчеризации....................... 13 Заключение ............................................................................................................ 15 2 1. Понятие синхронизации задач, проблема тупиков и взаимного исключения, критическая секция Синхронизация задач является фундаментальным аспектом в разработке и функционировании операционных систем, особенно в контексте многозадачности и операционных систем реального времени (ОСРВ). Этот процесс включает в себя механизмы и методы, которые позволяют задачам корректно и эффективно совместно использовать ресурсы, обеспечивая при этом их надежное выполнение в многозадачной среде. Проблема Тупиков (или взаимная блокировка) возникает, когда две или более задач ожидают освобождения ресурсов, занятых друг другом, что приводит к бесконечному ожиданию и полной остановке выполнения задач. Проблема тупиков является критической в системах, где требуется высокая степень надежности и доступности, поскольку она может привести к параличу всей системы. Взаимное исключение — это механизм, который обеспечивает, чтобы только одна задача могла использовать определенный ресурс в данный момент времени. Это ключевой метод предотвращения конфликтов доступа к ресурсам и является основой для решения проблемы синхронизации задач. Взаимное исключение позволяет системе поддерживать целостность данных и избегать ошибок в результате одновременного доступа к ресурсам. Критическая секция — это часть кода, доступ к которой должен быть строго контролируемым, чтобы обеспечить взаимное исключение при работе с общими ресурсами. Для защиты критических секций используются различные механизмы синхронизации, такие как мьютексы, семафоры и мониторы, которые позволяют регулировать доступ к предотвращать конфликты и ошибки в многозадачных системах. 3 ресурсам и 2. Семафоры и мьютексы, монитор, условная переменная. Для процессам синхронизации и потоков, выполняются в которые отдельных принадлежат адресных различным пространствах, операционная система предоставляет специальные объекты синхронизации. Эти объекты доступны всем потокам вне зависимости от их принадлежности к определенным процессам. Среди таких средств синхронизации выделяются системные семафоры, мьютексы, события, таймеры и прочие. В рамках синхронизационных инструментов операционных систем находят применение системные семафоры, мьютексы, условные переменные и мониторы. Рассмотрим детальнее каждый из этих элементов. Семафор – это объект, позволяющий войти в заданный участок кода не более чем n потокам. Специальный объект, позволяющий блокировать или активировать процесс, обратившийся к нему. Таким образом семафор решает проблемы: запрет одновременного выполнения заданных участков кода; поочерёдный доступ к критическому ресурсу (важному ресурсу, для которого невозможен одновременный доступ); синхронизация процессов и потоков Семафор — это объект, над которым можно выполнить три операции: 1) Инициализация семафора (задать начальное значение счетчика) 2) Захват семафора (ждать пока счетчик станет больше 0, после этого уменьшить счетчик на единицу) 3) Освобождение семафора (увеличить счетчик на единицу) В более сложных семафорах может использоваться очередь; при этом потоки, ожидающие освобождения семафора, будут проходить через семафор именно в том порядке, в котором они вызывали enter(). Мьютекс – особый вид двоичных семафоров, допускающий право владения. Мьютекс - одноместный семафор, служащий в программировании для синхронизации одновременно выполняющихся потоков. Его основное 4 назначение — организация взаимного исключения для потоков из одного и того же или из разных процессов. Двоичный семафор имеет два состояния – занят и свободен (signaled). У свободного мьютекса счетчик не растет и первое обращение wait «захватывает» мьютекс. Процесс при этом называется владельцем. Задача мьютекса — защита объекта от доступа к нему других потоков, отличных от того, который завладел мьютексом. В каждый конкретный момент только один поток может владеть объектом, защищённым мьютексом. Если другому потоку будет нужен доступ к переменной, защищённой мьютексом, то этот поток засыпает до тех пор, пока мьютекс не будет освобождён. С одной стороны, семафоры и мьютекс очень похожи. С другой, они имеют ряд значительных отличий: 1) Семафоры являются более гибкой формой мьютексов. В отличие от мьютексов, программа имеет контроль над тем, сколько потоков одновременно могут захватывать семафор. 2) Мьютекс может быть захвачен не более чем одним потоком управления. О потоке управления, который захватил мьютекс, говорят, что он является владельцем мьютекса. Освободить мьютекс может только его владелец. В силу этого мьютексы нельзя использовать в процедурах обработки прерываний. 3) Семафор предоставляет одновременный доступ к общему ресурсу не одному, а нескольким потокам. 4) Мьютексы в отличие от семафоров позволяют избежать инверсии приоритетов (менее приоритетные потоки управления в силу использования средств синхронизации мешают выполнению более приоритетного потока). 5 Монитор – это набор процедур и информационных структур, которыми процессы пользуются в режиме разделения, причем в фиксированный момент времени им может пользоваться только один процесс. Мониторы представляют собой тип данных и обладают собственными переменными, определяющими его состояние. Значения этих переменных извне могут быть изменены только с помощью вызова функций-методов, принадлежащих монитору. В свою очередь, эти функции-методы могут использовать в работе только данные, находящиеся внутри монитора, и свои параметры. Важной особенностью мониторов является то, что в любой момент времени только один процесс может быть активен, т. е. находиться в состоянии «готовность» или «исполнение», внутри данного монитора. Условные переменные так же, как и мьютексы, используются для управления доступом к ресурсам, которые совместно используются разными потоками управления. При этом условные переменные предоставляют больше возможностей, чем мьютексы. Мьютексы позволяют лишь получить монопольный доступ к общему ресурсу на некоторый период времени, а условные переменные позволяют получить такой доступ при выполнении определенного условия. Применение условных переменных основано на использовании двух операций: 1) ожидание выполнения условия, 2) сообщение о выполнении условия. При этом каждая условная переменная должна использоваться вместе с некоторым мьютексом. Этот мьютекс должен быть захвачен перед вызовом функции ожидания выполнения условия. 6 3. Проблема инверсии приоритетов, решения (протокол граничных приоритетов, протокол наследования приоритетов). Инверсия приоритетов. Комбинации приоритетов нитей и разделение между ними ресурсов приводит к классической проблеме инверсии приоритетов. Для создания условия инверсии приоритетов должно быть задействовано как минимум три нити. Если нить с самым низким приоритетом заблокировала ресурс (который она делит с самой высокоприоритетной нитью), в то время как работает нить с промежуточным приоритетом, возникает следующий эффект: нить с наивысшим приоритетом ожидает освобождения ресурса; нить с промежуточным приоритетом вытесняет низкоприоритетную нить и работает, пока не завершится; управление получает низкоприоритетная нить, которая освобождает ресурс, и только после этого нить с высоким приоритетом может продолжить свою работу. В этом случае время, необходимое для завершения нити с наивысшим приоритетом, зависит от времени работы нити с более низким приоритетом – это и есть инверсия приоритетов. Очевидно, что в такой ситуации высокоприоритетная нить может "прозевать" критическое событие. Протокол наследования В протоколе наследования приоритетов владелец взаимной блокировки наследует приоритет, который является максимальным среди приоритетов заблокированных нитей. Если нить блокируется при попытке захватить взаимную блокировку, владелец этой блокировки временно получает приоритет блокированной нити, если он больше его собственного приоритета. При освобождении взаимной блокировки приоритет восстанавливается. Рассмотрим протокол наследования приоритетов на примере. 7 владельца Допустим в системе существуют две задачи с низким (А) и высоким (Б) приоритетом: Рисунок 1. Система с задачами с разными приоритетами В момент T2 задача (Б) вытесняет низкоприоритетную задачу (А) и затем в момент времени T3 пытается захватить заблокированный (А) ресурс. Протокол наследования приоритета состоит в том, что приоритет задачи (А) повышается до приоритета задачи (Б) в момент времени T3, то есть когда (Б) пытается захватить заблокированный ресурс. Таким образом задачи с приоритетом больше (А) но меньше (Б) не могут реализовать неограниченную инверсию, и задача (Б) получит ресурс сразу после того, как (А) его разблокирует. После того как задача (А) разблокирует ресурс, ее приоритет понижается до исходного. Протокол граничных приоритетов В ряде случаев наследование приоритетов может оказаться не самым оптимальным решением. Примером здесь может служить ситуация, когда один высокоприоритетный поток разделяет много ресурсов с низкоприоритетными потоками — по одному ресурсу на каждый поток. В такой ситуации низкоприоритетных может возникнуть потоков положение, (вытесненных) когда много выстроятся перед высокоприоритетным. Но тогда длинный ряд последовательных операций 8 вытеснения («поштучно») и наследования приоритетов блокирующих потоков может привести к тому, что не хватит времени до окончания критического срока выполнения потока высокого приоритета, пока ОС будет анализировать ситуацию и последовательно проводить протокол наследования приоритетов. Именно для таких ситуаций и предназначен протокол граничного приоритета. Основная идея алгоритма состоит в том, что задача может вытеснить другую задачу, которая в настоящее время обращается к ресурсу и может обратиться к другому ресурсу, только если приоритет этого нового доступа будет выше, чем наиболее высокий из приоритетов, которые могут быть унаследованы выгружаемой задачей. Если используются семафоры, чтобы управлять доступом к ресурсу, каждому семафору назначается приоритет (перекрывающий) равный самому высокому приоритету всех задач, которые могут обратиться к этому семафору. 9 4. Диспетчеризация задач, определение. Диспетчеризация задач или процессов представляет собой процесс определения порядка, в котором процессы будут получать доступ к процессору для выполнения, когда они находятся в состоянии готовности. Этот процесс включает в себя перевод задачи из состояния готовности к выполнению в активное состояние выполнения. В течение жизненного цикла конкретного процесса он может неоднократно переходить между этими состояниями, то есть из готовности к выполнению и обратно, в зависимости от планирования процессорного времени. Учитывая, что в любой момент времени процессор может выполнять инструкции только одного процесса, диспетчеризация влечет за собой формирование и адаптацию очереди процессов, ожидающих выполнения. В основе такой очереди и других очередей в компьютерной системе лежат дескрипторы задач, которые представляют собой данные, идентифицирующие и содержащие информацию о состоянии каждой задачи на "физическом уровне". Эти дескрипторы задач служат критическим компонентом в механизме управления многозадачностью, позволяя операционной системе эффективно распределять процессорное время между множеством конкурирующих процессов и обеспечивая их своевременное выполнение в соответствии с заданными приоритетами и требованиями к ресурсам. 10 5. Состояние задачи, события, инициирующие смену состояния. Состояние характеризует способность задачи выполняться процессором. Любая задача в системе может находиться в одном из четырех состояний: a) Подвешенность – задача находится в этом состоянии, когда начинается или завершается. Такая задача не может исполняться процессором. b) Готовность – состояние задачи, которая готова к выполнению, но ещё не выполняется. c) Исполнение – состояние задачи, называемое активным. В любой момент времени на одном процессоре может исполняться только одна задача. d) Ожидание – задача чего-либо ожидает, обычно, завершения вводавывода, и при этом не может исполняться. [2] Переход задачи из одного состояния в другое регулируется совершением каких-либо событий. Событие – это оповещение процесса со стороны операционной системы о той или иной форме межпроцессного взаимодействия. Процесс исполняется до тех пор, пока не произойдет одно из следующих событий: - истёк выделенный ему квант времени; - процесс заблокирован, например, ждет завершения операции ввода/вывода; - процесс завершился; - вытеснен другим процессом, имеющим более высокий приоритет, например, обработчиком прерываний. Результатом совершения асинхронных событий являются системные прерывания. Внешние прерывания вызываются асинхронными событиями, которые происходят вне прерываемого процесса, например: прерывания от 11 таймера; прерывания от внешних устройств (прерывания по вводу/выводу); прерывания по нарушению питания; прерывания с пульта оператора вычислительной системы; прерывания от другого процессора или другой вычислительной системы. Внутренние прерывания вызываются событиями, которые связаны с работой процессора и являются синхронными с его операциями. Примерами являются следующие запросы на прерывания: при нарушении адресации (в адресной части выполняемой команды указан запрещенный или несуществующий адрес, обращение к отсутствующему сегменту или странице при организации механизмов виртуальной памяти); при наличии в поле кода операции незадействованной двоичной комбинации; при делении на нуль; при переполнении или исчезновении порядка; при обнаружении ошибок четности, ошибок в работе различных устройств аппаратуры средствами контроля. 12 6. Статические и динамические алгоритмы диспетчеризации В контексте операционных систем реального времени (ОСРВ), ключевым элементом является диспетчеризация - процесс определения порядка доступа процессов к процессору. Эффективное управление задачами и их исполнением, особенно с учетом дедлайнов, становится критически важным. Задачи должны быть запланированы таким образом, чтобы каждая из них была выполнена вовремя. При невозможности гарантировать выполнение задачи до ее дедлайна, она должна быть отклонена. Статические Алгоритмы Диспетчеризации Статические алгоритмы планирования, такие как Rate Monotonic Scheduling (RMS), предполагают составление расписания запуска задач заранее, до начала работы системы. Планировщик следует этому расписанию без его изменения в процессе работы, что особенно применимо к периодическим задачам. В случае наличия спорадических задач, планировщик должен адаптироваться, выбирая моменты их запуска на основе текущих условий. Преимущества статических алгоритмов включают в себя их простоту, поскольку они не требуют понятия процесса/потока, а передача управления задаче осуществляется через вызов подпрограммы. Это обеспечивает высокую надежность результатов тестирования и проверок, делая статические алгоритмы предпочтительными в критически важных системах, таких как автопилоты. Основные недостатки статических алгоритмов включают их негибкость, так как любые изменения требуют остановки системы и пересчета расписания, а также сложность учета спорадических задач и потенциально большие размеры таблиц расписаний. Динамические Алгоритмы Диспетчеризации 13 Динамические алгоритмы, такие как Earliest Deadline First (EDF) и Least Laxity First (LLF), основаны на динамическом приоритете задач. В любой момент времени наибольший приоритет получает задача, требующая немедленного выполнения, либо из-за приближающегося дедлайна (EDF), либо из-за минимального запаса времени (LLF). Динамические алгоритмы могут быть как вытесняющими, так и не вытесняющими. Вытесняющие алгоритмы позволяют прервать текущую задачу для выполнения более приоритетной, в то время как не вытесняющие доводят текущую задачу до конца, даже если появляются задачи с более высоким приоритетом. Эти алгоритмы считаются оптимальными при определенных условиях: независимость всех задач, возможность вытеснения и отсутствие временных затрат на вытеснение. Однако, в реальных условиях вытеснение влечет за собой дополнительные временные затраты, что необходимо учитывать при выборе алгоритма диспетчеризации. В среде динамического планирования со статическими приоритетами приоритет задачи остается неизменным на протяжении всего времени ее исполнения, что подходит для систем с периодическими задачами, где требуется стабильность и предсказуемость выполнения задач. В заключение выбор между статическими и динамическими алгоритмами диспетчеризации зависит от конкретных требований к системе, ее архитектуры и задач, которые она должна выполнять. Каждый из подходов имеет свои преимущества и недостатки, которые следует взвешивать, принимая во внимание специфику приложения и требования к его работе. 14 Заключение Можно сделать вывод о том, что синхронизация и диспетчеризация задач в операционных системах реального времени играют ключевую роль. Были изучены статические и динамические методы диспетчеризации, выделены их достоинства и ограничения, а также обсуждены уникальные механизмы, например протоколы наследования приоритетов, которые помогают решать проблему инверсии приоритетов. Выбор подходящего алгоритма зависит от специфических требований системы и задач, подчеркивая важность нахождения баланса адаптивностью в управлении процессами. 15 между надежностью и Список литературы 1) Планирование и диспетчеризация процессов. Дескрипторы задач. URL: https://studfile.net/preview/919468/# (дата обращения: 19.02.2024) 2) Состояния задачи. URL: https://it.wikireading.ru/6158 (дата обращения: 19.02.2024) 3) Горошко Егор, «Операционные системы реального времени» 4) И. Б. Бурдонов, А. С. Косачев, В. Н. Пономаренко. «Операционные системы реального времени» 5) Понятие приоритета и очереди https://studfile.net/preview/1582714/page:5/ 19.02.2024) 16 процессов. (дата URL: обращения:
