Потоки реального времени в ос семейства windows nt имеют приоритет равный

Сегодня становится широко распространенным желание потребителей использовать Windows NT в системах реального времени. Для этого имеется ряд весомых, на первый взгляд, причин: Win32 API считается стандартом, а на его базе разработано огромное количество программ; графический интерфейс стал сегодня очень популярным; для NT имеется немало готовых решений для коммерческих применений; в среду NT включены многие виды средств разработки. Тем не менее, возможно ли использование Windows NT для разработки системы реального времени?

Сегодня становится широко распространенным желание потребителей использовать Windows NT в системах реального времени. Для этого имеется ряд весомых, на первый взгляд, причин: Win32 API считается стандартом, а на его базе разработано огромное количество программ; графический интерфейс стал сегодня очень популярным; для NT имеется немало готовых решений для коммерческих применений; в среду NT включены многие виды средств разработки. Тем не менее, возможно ли использование Windows NT для разработки системы реального времени?

Несмотря на то, что сегодня Windows NT не отвечает в полной мере требованиям, предъявляемым к операционной системе реального времени, давление рынка привело к появлению коммерческих решений, расширяющих NT возможностями обработки в реальном времени.

1. «Жесткие» и «мягкие» системы реального времени

Система реального времени (СРВ) — это аппаратно-программный комплекс, который должен своевременно и предсказуемо реагировать на поступающие извне раздражители. Основное требование к СРВ — своевременность обработки событий. Реакция на событие должна уложиться в пределы заранее определенного лимита времени, а превышение этого лимита или опоздание считается программным сбоем.

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

Еще одним важным требованием к СРВ является одновременная обработка событий: если несколько событий происходят одновременно, все они должны быть обработаны своевременно. Это означает, что имманентным свойством системы реального времени должен быть параллелизм. Чтобы этого добиться, необходимо установить более одного процессора или придерживаться многозадачного подхода.

В зависимости от отношения к опозданиям системы реального времени делятся на «жесткие» (hard) и «мягкие» (soft).

В жесткой системе:

  • опоздания не допускаются ни при каких обстоятельствах;
  • в случае опоздания результаты обработки уже никому не нужны;
  • опоздание считается катастрофическим сбоем;
  • стоимость опоздания бесконечно велика.

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

В мягкой системе реального времени:

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

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

Итак, разница между жесткой и мягкой системами зависит от предъявляемых к ним требований. Система называется жесткой, если «система не должна опаздывать никогда», и мягкой, если «система не должна опаздывать, как правило».

Не следует путать операционную систему реального времени (ОС РВ) с системой реального времени. Первая ОС используется для создания системы реального времени. ОС РВ должна быть предсказуемой — это не значит, что она должна быть быстрой, это означает, что при построении СРВ можно добиться того, чтобы максимальное время, затрачиваемое на определенную работу, укладывалось в заранее установленный лимит, сравнимый с требованиями приложения. Windows 3.11, например, даже на сколь угодно быстром процессоре бесполезна для построения СРВ, поскольку любое приложение может захватить управление и заблокировать все остальное.

2. Удовлетворяет ли Windows NT требованиям, предъявляемым к ОС РВ?

2.1. Нити и приоритеты

Очевидно, что NT — многонитевая ОС, она позволяет вытеснение и тем самым удовлетворяет требованию 1 (см. врезку).

В Windows NT имеются два класса приоритетов: класс реального времени и динамический класс. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, тогда как приоритет процессов динамического класса может меняться диспетчером. Процесс имеет базовый уровень приоритета. Нить в процессе может иметь приоритет в диапазоне плюс/минус 2 около базового уровня или один из двух крайних уровней класса (16 или 31 для реального времени). Например, нить в процессе с базовым уровнем 24 может иметь приоритет 16, 22 — 26, 31. Очевидно, что гарантировать предсказуемость системы можно только при использовании процессов первого класса.

Казалось бы, второе требование также удовлетворено. Но малое число возможных уровней препятствует реализации СРВ на базе NT. Большинство современных ОС РВ позволяет иметь по крайней мере 256 различных уровней. Чем больше имеется уровней, тем более предсказуемо поведение системы. В Windows NT имеется только 7 различных уровней для нити в данном процессе. В результате многие нити будут выполняться с одинаковыми приоритетами и, как следствие, предсказуемость поведения системы будет посредственной. Более того, общее число уровней для всех процессов класса только 16 и положение не спасает даже замена нитей процессами, не говоря уже о том, что переключение контекста для процессов снижает производительность.

В ОС РВ вызовы системы синхронизации (семафоры или критические секции) должны уметь управлять наследованием приоритетов. В Windows NT это невозможно, поэтому требование 4 не удовлетворяется.

Еще одна проблема обусловлена реализацией некоторых вызовов системы GUI. Они обрабатываются синхронно (вызывающая нить приостанавливается, пока не завершится системный вызов) процессом, выполняемым с более низким приоритетом (динамического класса). В результате нить может помешать нити с более высоким приоритетом — возникает инверсия приоритета.

Таким образом, малое число приоритетов и невозможность решить проблему инверсии делают Windows NT пригодной только для очень простых СРВ.

2.2. Предсказуемость системных вызовов Win32 API

Для тестирования системных вызовов был написан процесс (принадлежащий классу реального времени), содержащий вызовы системы синхронизации нитей, и измерялось время, затраченное на каждый вызов. При запуске на Pentium 100 МГц с 24 Мбайт памяти оказалось, что максимальное значение на вызове mutex достигает 670 мкс при среднем времени 35 мкс. Это произошло потому, что во время работы теста происходили обращения к диску и по сети. Если компьютер искусственно загрузить обращениями к диску и сетевой обработкой, то задержки возрастают аж до нескольких миллисекунд. Win32 API очень богат, но не предназначен для реального времени. Например, запросы mutex обрабатываются в порядке поступления, а не в порядке приоритетов, что снижает предсказуемость. Для синхронизации нитей в одном процессе критические секции следует предпочесть всем другим способам (этот вызов затрачивает всего несколько мкс по сравнению с 35 мкс на вызов mutex).

Несмотря на все достоинства API, ядро и менеджер ввода/вывода Windows NT недостаточно приспособлены к обработке событий реального времени на уровне приложений.

2.3. Управление прерываниями в NT

В Windows NT единственный способ управления аппаратурой — через драйвер устройства. Поскольку приложение реального времени имеет дело с внешними событиями, разработчик должен написать и включить в ядро драйвер устройства, дающий доступ к аппаратуре. Этот драйвер реагирует на прерывания, генерируемые соответствующим устройством.

Прерывания обрабатываются в два этапа. Сначала выполняется очень короткая программа обслуживания прерываний (ISR). Впоследствии работа завершается выполнением DPC — процедуры отложенного вызова. Возникает следующий поток событий:

  • Происходит прерывание.
  • Процессор сохраняет PC, SP и вызывает диспетчер.
  • ОС сохраняет контекст и вызывает ISR.
  • В ISR выполняется критическая работа (чтение/запись аппаратных регистров).
  • DPC ставится в очередь.
  • ОС восстанавливает контекст.
  • Процессор восстанавливает PC, SP.
  • Ожидающие в очереди DPC выполняются на уровне приоритета DISPATCH_LEVEL.
  • После завершения всех DPC ОС переходит к выполнению приложений.

ISR должно быть как можно короче, поэтому большинство драйверов выполняют значительную часть работы в DPC (которая может быть вытеснена другим ISR), ожидая окончания других DPC, ранее попавших в очередь (все DPC имеют одинаковый приоритет).

Из документации по NT следует, что ISR может быть вытеснена другим ISR с более высоким приоритетом, и что DPC имеет более высокий приоритет, чем пользовательские и системные нити. Но поскольку все DPC имеют одинаковый уровень приоритета и ISR должна быть сведена к минимуму, ваш DPC будет вынужден ждать других и ваше приложение будет зависеть от остальных драйверов устройств непредсказуемым образом. Задержки системных вызовов, описанные в предыдущем разделе, обусловлены именно тем, что DPC от драйверов жесткого диска и сети блокируют все другие.

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

2.4. Управление памятью в NT

Другим важным моментом при проектировании СРВ является политика управления памятью в ОС РВ. В Windows NT процессы выполняются в своем собственном пространстве памяти. Добиться этого позволяют механизмы виртуальной памяти и подкачки. Для бизнес-приложений это хорошо, но для СРВ, которая должна реагировать на внешние события с заранее определенным лимитом времени, это порождает непредсказуемость, особенно если система отправит страницу из памяти на диск. Windows NT позволяет захватить страницу в памяти посредством вызова функции VirtualLock. Тем не менее NT может разблокировать страницу и выгрузить ее на диск, если весь процесс неактивен

3. Может ли Windows NT использоваться в качестве ОС РВ?

Итак, можно сделать вывод, что Windows NT, предназначенная в основном для классических приложений, не является хорошей платформой для поддержания обработки в реальном времени. Тем не менее на ее базе можно все-таки построить простую мягкую СРВ, время от времени допускающую опоздания.Следующие обстоятельства могут облегчить построение СРВ на базе NT:

  • загрузка CPU низка (DPC имеют достаточно времени);
  • критическая работа (или даже вся) делается на уровне DPC или (еще лучше) на уровне ISR. В таком случае непонятно, зачем вообще нужна ОС.

Но для жесткой СРВ использование Windows NT невозможно — система реального времени никогда не будет предсказуемой.Что следует изменить в Windows NT, чтобы ее можно было использовать в жестких СРВ?

a) Класс процессов реального времени должен иметь больше уровней.

б) Необходимо решить проблему инверсии приоритетов.

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

г) Система прерываний должна быть заменена целиком:

  • DPC должны иметь много уровней приоритетов.
  • DPC должны быть вытесняемыми более приоритетными DPC.
  • Драйверы от третьих фирм и системные драйверы должны быть настраиваемыми (уровни прерываний ISR, уровни прерываний DPC)
  • Драйверы от третьих фирм должны быть открыты для разработчиков, должно быть известно по крайней мере максимальное время, затрачиваемое на работу ISR и DPC.
  • Должно быть известно время маскирования прерываний.

Готовы ли разработчики Microsoft ввести эти усовершенствования в NT или они полагают, что рынок слишком мал, и оставят его свободным для третьих фирм?

4. Коммерческие решения, расширяющие NT возможностями обработки в реальном времени

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

  • Использование NT как она есть для построения мягкой системы реального времени.
  • Реализация Win32 API над другой ОС РВ.
  • Совместная работа на одном процессоре NT и другой ОС РВ (или ее части).
  • Использование мультипроцессорной архитектуры, когда NT выполняется на одном процессоре (или более), а часть реального времени — на остальных.

Во многих решениях производители модифицируют HAL или ядро NT. Политика Microsoft заключается в том, чтобы не допускать никаких модификаций ядра NT, кроме драйверов устройств. Это единственно возможный способ связи с ядром. Политика компании относительно HAL другая. HAL (Hardware Abstraction Layer) — уровень аппаратных абстракций — уровень, лежащий ниже программного обеспечения, который виртуализирует интерфейс NT с аппаратурой, допуская переносимость NT с одной аппаратной платформы на другую. Такие модификации HAL, как манипуляции с часами или замена методов обработки прерываний, представляются беспримерно незаконным использованием HAL. Они создают нестандартную среду и могут привести к проблемам сопровождения, если, например, Microsoft изменит HAL в следующих версиях. Поэтому различие в решениях, предлагаемых поставщиками, заключается в попытках сделать модификации HAL минимальными.

Также возможен перехват HAL посредством трюков с процессором Intel. Однако это можно реализовать только на платформе Intel. Механизмы перехвата посредством обработки исключительных ситуаций на уровне устройства поглощают определенную вычислительную мощность.

4.1. Использование NT как таковой

Подобное применение предполагает включение структур, обрабатывающих прерывания. Однако учитывая, что NT не предназначена для обработки в реальном времени это надо делать очень аккуратно.

Иногда вводят усовершенствования в механизм обработки прерываний. Единственный способ сделать это — перехватить прерывание, для чего необходимо добавить специальное аппаратное расширение. LP-Elektronik, например, перехватывает прерывание и использует затем NMI (немаскируемое прерывание, не используемое на уровне NT) для обработки событий реального времени. Этот подход применим только тогда, когда процессор имеет отдельный стек прерываний. Программа NMI должна быть написана аккуратно: в ней нельзя использовать вызовы ОС и она должна быть как можно короче, чтобы не потерять другие прерывания. Такое решение дает минимальную задержку прерывания, но требует дополнительной аппаратуры. Как и в других решениях, здесь необходим дополнительный механизм связи между NT и частью реального времени. Разница в том, что при этом требуется большая аккуратность в использовании NMI.

4.2. Реализация Win32 API над другой ОС РВ

Добавление Win32 API к ОС, предназначенной для обработки в реальном времени, избавляет от необходимости модифицировать HAL или использовать другие трюки с NT. Преимущества такого подхода:

  • имеется переносимость,
  • небольшой след,
  • поведение ОС РВ известно.

Недостатки:

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

Среди коммерческих реализаций этого подхода — QNX и VxWorks, использующие библиотеку Willows.

4.3. Совместная работа на одном процессоре NT и ОС РВ

Мощность современных процессоров достаточна для одновременного функционирования NT и программ реального времени. Возможны две разновидности такого подхода:

  • модификация HAL c перехватом прерываний и включением небольшого диспетчера или ОС РВ;
  • выполнение NT, как одной из задач над (супервизором) ОС РВ.

В любом случае HAL должен быть модифицирован или по крайней мере перехвачен. В основном все такие решения похожи. В качестве иллюстрации можно привести следующее возможное решение с модификацией HAL.

Программу голубого экрана NT можно рассматривать, как упрощенную программу супервизора. Модифицируя ее внутри HAL, можно сделать простой мультизадачный механизм выхода из нее, запустить NT, как одну из задач с самым низким приоритетом и запустить нечто другое, как другую задачу. Это нечто другое может быть набором задач реального времени или полной ОС РВ.

В обоих случаях необходим механизм связи между частями реального времени и NT. Он может быть выполнен одним из двух способов. Первый заключается во введении альтернативного механизма межпроцессорных связей (IPC). Проще всего реализовать IPC с помощью разделяемой памяти. Недостатком такого протокола IPC является уровень приоритета, на котором выполняются пользовательские приложения NT. При втором способе интерфейс реализуется с помощью драйвера устройства, в результате чего у NT создается впечатление, что подсистема реального времени — это устройство.

Задачи реального времени используют собственный интерфейс с системой, в большинстве случаев отличный от Win32 API. Среда разработки может быть обычной для используемой ОС РВ средой и может взаимодействовать со средой NT. Задачи реального времени будут выполняться, не получая преимуществ от механизма защиты памяти NT. Особо аккуратно следует продолжать выполнение частей реального времени, когда NT рухнет и сгенерирует голубой экран. След памяти — это комбинация следа NT (8 Мбайт в стандартной конфигурации) плюс минимальные требования для части ОС РВ.

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

  • Сохранение (почти) всей среды NT нетронутой означает, что все программное обеспечение, устройства и драйверы устройств NT можно использовать (чтобы выполнять части приложения, не связанные с реальным временем). Поддерживается совместимость с NT;
  • Можно включить защиту для задач реального времени, зависящую от используемой ОС РВ.

Недостатки:

  • Отсутствует переносимость между реальным временем и средой NT, за исключением случая, когда RT-API разработан на базе Win32;
  • драйверы устройств NT нельзя использовать в части реального времени;
  • Среда разработки усложняется, если для задач реального времени требуется отдельная среда;
  • Может быть много уровней задач и поэтому много уровней определений контекста. Переключение этих контекстов требует времени.

Известны следующие коммерческие реализации подхода, не требующего модификации аппаратуры: IMAGINATION с HyperKERNEL; RADISYS с комбинацией iRMX/NT; VenturCom с RTX, KPX и RTAPI.

В реализации фирмы RadiSys ОС РВ iRMX работает, как первичная ОС, загружающая Windows NT в качестве низкоприоритетной задачи. Пользователь работает только с NT, не видя и не чувствуя iRMX. Все управляющие функции выполняются, как высокоприоритетные задачи iRMX, изолированные в памяти от приложений и драйверов NT. Используя функции защиты памяти внутри процессора Intel, Windows NT защищена от задач реального времени.

Комбинация iRMX/NT преодолела трудности, которые возникают при модификации HAL и оставляют пользователя уязвимым при сбоях жесткого диска, сбоях драйверов и системных сбоях NT («голубой экран смерти»). В этом решении управляющая программа в случае краха NT может либо продолжить нормальное выполнение, либо произвести правильное закрытие системы (shutdown).

Реализация фирмы VenturCom состоит из двух этапов. На первом — мягкая реализация RTX 3.1 содержит интерфейс прикладной программы реального времени RTAPI, который дает время реакции 1-5 мск. RTAPI 1.0 работает со стандартным NT. Единственное изменение, обеспечивающее лучшую синхронизацию событий реального времени, внесено в часы. Так как в Windows NT имеются некоторые плохо предсказуемые процессы, то RTAPI позволит построить только мягкую СРВ с небольшим временем отклика, но недостаточно предсказуемую. Впрочем, большую часть непредсказуемости NT можно устранить, ограничив доступ к системному диску и сети.

Чтобы сделать NT более предсказуемой, необходимо прерывать ее внутренние задачи. В основе второй жесткой реализации RTX 4.1 лежит модификация HAL. В обеспечении детерминизма важную роль играют программируемые часы. В каждый тик часов — аппаратное прерывание с регулярными интервалами времени — предпочтение отдается задаче реального времени. Оставшееся время предоставляется процессам NT, в том числе и процессам мягкого реального времени. Чем чаще тикают часы, тем больше возможностей у процессора для выполнения задач реального времени. Необходимо добиться баланса между многими факторами: частота тиков, время, выделенное для обработки в реальном времени, время, выделенное для выполнения задач NT.

4.4. Использование многопроцессорной архитектуры

Простое решение здесь состоит в том, что NT выполняется на одной группе процессоров, а часть реального времени — на другой. Возможно применение архитектур параллельной шины с VMEbus, PCI, PMC или архитектур последовательной шины с Ethernet. Если необходимо, подсистемы могут быть связаны механизмом IPC и процедурами удаленного вызова. Преимущества такого решения:

  • Нет модификаций каждой ОС;
  • Можно применять в больших сложных системах;
  • Для каждой подсистемы можно выбрать свою, наиболее подходящую ОС РВ;
  • Можно использовать имеющиеся среды разработки.

Недостатки:

  • Высокая стоимость;
  • Поведение в реальном времени зависит от поведения канала межпроцессорной связи. Поведение прерываний на шине в таких структурах предсказуемо лишь при хорошей организации;
  • Среды разработки относятся к разным мирам.

***

Чудес не бывает. Если вы хотите сохранить высокую совместимость с NT, то надо будет заплатить и более высокую цену. Если вы интересуетесь только частью интерфейса Win32 API, то можете работать с ОС РВ, имеющей этот интерфейс.

Имеется множество запросов на комбинации NT и РВ. Даже если это и не лучшее решение, рынок должен следовать желаниям заказчика. Разумеется, лучше всего было бы регулярное модифицировать саму Windows NT. Но пока компания Microsoft оставляет эту нишу свободной и она спонтанно заполняется производителями, зачастую использующими разные трюки, приводящие к несовместимости. Следует помнить, что использование трюков может в будущем привести к проблемам сопровождения.


Необходимые требования к ОС для обеспечения предсказуемости

Требование 1. ОС РВ должна быть многонитевой и допускать вытеснение (preemtible).

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

Требование 2. Диспетчеризация должна осуществляться на базе приоритетов.

Основная сложность диспетчеризации заключается в том, чтобы обнаружить, какая именно нить нуждается в ресурсах в первую очередь. В идеале ОС РВ предоставляет ресурсы той нити или драйверу, которым осталось меньше всего времени до установленного срока. Чтобы сделать это, ОС должна знать, когда нить обязана завершить свою работу и сколько времени ей понадобится. Поскольку это очень трудно реализовать, таких ОС пока еще не существует. Поэтому механизм диспетчеризации потоков управления в современных ОС базируется на понятии приоритета: ресурсы предоставляются нити с наивысшим приоритетом.

Требование 3. Механизм синхронизации нитей должен быть предсказуемым.

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

Требование 4. Должна существовать система наследования приоритетов.

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

Чтобы избежать этого, ОС РВ должна допускать «наследование» приоритета, подталкивая нить с низшим приоритетом. Наследование приоритета означает, что блокирующая нить наследует приоритет нити, которую она блокирует (конечно, только если последняя обладает более высоким приоритетом).

Требование 5. Временные характеристики ОС должны быть предсказуемы и известны.

Разработчик СРВ должен знать, сколько времени затрачивается на ту или иную системную работу. Кроме того, должны быть известны уровни системных прерываний и уровни IRQ (линий запросов прерываний) драйверов устройств, максимальное время, которое они затрачивают и т.п.

Евгений Хухлаев — сотрудник Института прикладной математики имени М.В. Келдыша РАН, (Москва).

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

41

int init_module(void)

{

/* определить номер очереди сообщений */

#define RTFIFODESC 1

/* взять локальное время */

RTIME now = rt_get_time() rt_task_init(&mytask, mainloop,

RTFIFODESC,3000, 4); rt_task_make_periodic(&mytask,

now+1000, 25000); return 0;

}

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

Оба подхода в реализации механизмов реального времени, заложенные в KURT и RTLinux, применимы для большинства задач реального времени. Многие разработчики уже приняли Linux и внедря

ют ее в своих коммерческих проектах как основную операционную систему для серверов приложений. Однако до сих пор при реализации вертикальных проектов на нижнем уровне применялись специализированные ОС реального времени. Ситуация может существенно

измениться благодаря использованию расширений реального времени для Linux.

Сегодня становится широко распространенным желание потребителей использовать Windows NT в системах реального времени [9]. Для этого имеется ряд весомых, на первый взгляд, причин: Win32 API считается стандартом, а на его базе разработано огромное количество

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

42

программ; графический интерфейс стал сегодня очень популярным; для NT имеется немало готовых решений для коммерческих применений; в среду NT включены многие виды средств разработки. Тем не менее, возможно ли использование Windows для разработки системы реального времени?

Перечислим необходимые требования к ОС для обеспечения предсказуемости.

Требование 1. ОС РВ должна быть многонитевой и допускать вытеснение (preemtible).

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

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

Требование 2. Диспетчеризация должна осуществляться на базе приоритетов.

Основная сложность диспетчеризации заключается в том, чтобы обнаружить, какая именно нить нуждается в ресурсах в первую очередь. В идеале ОС РВ предоставляет ресурсы той нити или драйверу, которым осталось меньше всего времени до установленного срока. Чтобы сделать это, ОС должна знать, когда нить обязана завершить свою работу и сколько времени ей понадобится. Поскольку это очень трудно реализовать, таких ОС пока еще не существует. Поэтому механизм диспетчеризации потоков управления в современных ОС базируется на понятии приоритета: ресурсы предоставляются нити с наивысшим приоритетом.

Требование 3. Механизм синхронизации нитей должен быть предсказуемым.

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

Требование 4. Должна существовать система наследования приоритетов.

Разделение нитями с разными приоритетами общих ресурсов может привести к классической проблеме инверсии приоритетов. Чтобы избежать этого, ОС РВ должна допускать «наследование» приоритета, подталкивая нить с низшим приоритетом. Наследование

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

43

приоритета означает, что блокирующая нить наследует приоритет нити, которую она блокирует (конечно, только если последняя обладает более высоким приоритетом).

Требование 5. Временные характеристики ОС должны быть предсказуемы и известны.

Разработчик СРВ должен знать, сколько времени затрачивается на ту или иную системную работу. Кроме того, должны быть известны уровни системных прерываний и уровни IRQ (линий запросов прерываний) драйверов устройств, максимальное время, которое они затрачивают и т.п.

Несмотря на то, что сегодня Windows NT не отвечает в полной мере требованиям, предъявляемым к операционной системе реального времени, давление рынка привело к появлению коммерческих решений, расширяющих NT возможностями обработки в реальном времени.

Удовлетворяет ли Windows NT требованиям, предъявляемым к ОС РВ?

Очевидно, что NT многонитевая ОС, она позволяет вытеснение

итем самым удовлетворяет требованию 1.

ВWindows NT имеются два класса приоритетов: класс реального времени и динамический класс. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, тогда как приоритет процессов динамического класса может меняться диспетчером. Процесс имеет базовый уровень приоритета. Нить в процессе может иметь приоритет в диапазоне плюс/минус 2 около базового уровня или один из двух крайних уровней класса (16 или 31 для реального времени). Например, нить в процессе с базовым уровнем 24 может иметь приоритет 16, 22 – 26, 31. Очевидно, что гарантировать предсказуемость системы можно только при использовании процессов первого класса.

Казалось бы, второе требование также удовлетворено. Но малое число возможных уровней препятствует реализации СРВ на базе NT.

Большинство современных ОС РВ позволяет иметь по крайней мере 256 различных уровней. Чем больше имеется уровней, тем более предсказуемо поведение системы. В Windows NT имеется только 7 различных уровней для нити в данном процессе. В результате многие нити будут выполняться с одинаковыми приоритетами и, как следствие, предсказуемость поведения системы будет посредственной. Бо

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

44

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

ВОС РВ вызовы системы синхронизации (семафоры или критические секции) должны уметь управлять наследованием приоритетов.

ВWindows NT это невозможно, поэтому требование 4 не удовлетворяется.

Еще одна проблема обусловлена реализацией некоторых вызовов системы GUI. Они обрабатываются синхронно (вызывающая нить приостанавливается, пока не завершится системный вызов) процессом, выполняемым с более низким приоритетом (динамического класса). В результате нить может помешать нити с более высоким приоритетом возникает инверсия приоритета.

Таким образом, малое число приоритетов и невозможность решить проблему инверсии делают Windows NT пригодной только для очень простых СРВ.

Предсказуемость системных вызовов Win32 API.

Для тестирования системных вызовов был написан процесс (принадлежащий классу реального времени), содержащий вызовы системы синхронизации нитей, и измерялось время, затраченное на каждый вызов. Максимальное значение на вызове mutex достигает 670 мкс при среднем времени 35 мкс. Это произошло потому, что во время работы теста происходили обращения к диску и по сети. Если

компьютер искусственно загрузить обращениями к диску и сетевой обработкой, то задержки возрастают до нескольких миллисекунд. Win32 API очень богат, но не предназначен для реального времени. Например, запросы mutex обрабатываются в порядке поступления, а не в порядке приоритетов, что снижает предсказуемость. Для синхронизации нитей в одном процессе критические секции следует предпочесть всем другим способам (этот вызов затрачивает всего несколько мкс по сравнению с 35 мкс на вызов mutex).

Несмотря на все достоинства API, ядро и менеджер ввода/вывода Windows NT недостаточно приспособлены к обработке событий реального времени на уровне приложений.

Управление прерываниями в NT.

ВWindows NT единственный способ управления аппаратурой через драйвер устройства. Поскольку приложение реального времени

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

45

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

Прерывания обрабатываются в два этапа. Сначала выполняется очень короткая программа обслуживания прерываний (ISR). Впоследствии работа завершается выполнением DPC процедуры отложенного вызова. Возникает следующий поток событий:

§Происходит прерывание.

§Процессор сохраняет PC, SP и вызывает диспетчер.

§ОС сохраняет контекст и вызывает ISR.

§В ISR выполняется критическая работа (чтение/запись аппаратных регистров).

§DPC ставится в очередь.

§ОС восстанавливает контекст.

§Процессор восстанавливает PC, SP.

§Ожидающие в очереди DPC выполняются на уровне приори

тета DISPATCH_LEVEL.

§После завершения всех DPC ОС переходит к выполнению приложений.

ISR должно быть как можно короче, поэтому большинство драйверов выполняют значительную часть работы в DPC (которая может быть вытеснена другим ISR), ожидая окончания других DPC, ранее попавших в очередь (все DPC имеют одинаковый приоритет).

Из документации по NT следует, что ISR может быть вытеснена другим ISR с более высоким приоритетом, и что DPC имеет более высокий приоритет, чем пользовательские и системные нити. Но поскольку все DPC имеют одинаковый уровень приоритета и ISR должна быть сведена к минимуму, ваш DPC будет вынужден ждать других

и ваше приложение будет зависеть от остальных драйверов устройств непредсказуемым образом. Задержки системных вызовов, описанные в предыдущем разделе, обусловлены именно тем, что DPC от драйверов жесткого диска и сети блокируют все другие.

В настоящих ОС РВ разработчик знает, на каком уровне выполняются драйверы всех других устройств. Обычно имеется свободное

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

46

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

Управление памятью в NT.

Другим важным моментом при проектировании СРВ является политика управления памятью в ОС РВ. В Windows NT процессы выполняются в своем собственном пространстве памяти. Добиться этого позволяют механизмы виртуальной памяти и подкачки. Для бизнесприложений это хорошо, но для СРВ, которая должна реагировать на внешние события с заранее определенным лимитом времени, это порождает непредсказуемость, особенно если система отправит страницу из памяти на диск. Windows NT позволяет захватить страницу в памяти посредством вызова функции VirtualLock. Тем не менее NT может разблокировать страницу и выгрузить ее на диск, если весь

процесс неактивен

Может ли Windows NT использоваться в качестве ОС РВ?

Итак, можно сделать вывод, что Windows NT, предназначенная в основном для классических приложений, не является хорошей платформой для поддержания обработки в реальном времени. Тем не менее на ее базе можно всетаки построить простую мягкую СРВ, время от времени допускающую опоздания. Следующие обстоятельства могут облегчить построение СРВ на базе NT:

§загрузка CPU низка (DPC имеют достаточно времени);

§критическая работа (или даже вся) делается на уровне DPC или (еще лучше) на уровне ISR. В таком случае непонятно, зачем вообще нужна ОС.

Но для жесткой СРВ использование Windows NT невозможно система реального времени никогда не будет предсказуемой.Что следует изменить в Windows NT, чтобы ее можно было использовать в жестких СРВ?

a) Класс процессов реального времени должен иметь больше уровней.

б) Необходимо решить проблему инверсии приоритетов.

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

г) Система прерываний должна быть заменена целиком:

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

47

§DPC должны иметь много уровней приоритетов;

§DPC должны быть вытесняемыми более приоритетными

DPC.

§драйверы от третьих фирм и системные драйверы должны быть настраиваемыми (уровни прерываний ISR, уровни прерываний DPC);

§драйверы от третьих фирм должны быть открыты для разработчиков, должно быть известно по крайней мере максимальное время, затрачиваемое на работу ISR и DPC;

§должно быть известно время маскирования прерываний.

Коммерческие решения, расширяющие NT возможностями обработки в реальном времени.

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

§использование NT как она есть для построения мягкой системы реального времени;

§реализация Win32 API над другой ОС РВ;

§совместная работа на одном процессоре NT и другой ОС РВ (или ее части);

§использование мультипроцессорной архитектуры, когда NT выполняется на одном процессоре (или более), а часть реального времени на остальных.

Во многих решениях производители модифицируют HAL или ядро NT. Политика Microsoft заключается в том, чтобы не допускать никаких модификаций ядра NT, кроме драйверов устройств. Это единственно возможный способ связи с ядром. Политика компании относительно HAL другая. HAL (Hardware Abstraction Layer) – уро

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

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

48

ях, предлагаемых поставщиками, заключается в попытках сделать модификации HAL минимальными.

Также возможен перехват HAL посредством трюков с процессором Intel. Однако это можно реализовать только на платформе Intel. Механизмы перехвата посредством обработки исключительных ситуаций на уровне устройства поглощают определенную вычислительную мощность.

Использование NT как таковой.

Подобное применение предполагает включение структур, обрабатывающих прерывания. Однако учитывая, что NT не предназначена для обработки в реальном времени это надо делать очень аккуратно.

Иногда вводят усовершенствования в механизм обработки прерываний. Единственный способ сделать это перехватить прерывание, для чего необходимо добавить специальное аппаратное расширение. LP-Elektronik, например, перехватывает прерывание и использует затем NMI (немаскируемое прерывание, не используемое на уровне NT) для обработки событий реального времени. Этот подход применим только тогда, когда процессор имеет отдельный стек прерываний. Программа NMI должна быть написана аккуратно: в ней нельзя использовать вызовы ОС и она должна быть как можно короче, чтобы не потерять другие прерывания. Такое решение дает минимальную задержку прерывания, но требует дополнительной аппаратуры. Как и в других решениях, здесь необходим дополнительный механизм связи между NT и частью реального времени. Разница в том, что при этом требуется большая аккуратность в использовании

NMI.

Реализация Win32 API над другой ОС РВ.

Добавление Win32 API к ОС, предназначенной для обработки в реальном времени, избавляет от необходимости модифицировать HAL или использовать другие трюки с NT.

Преимущества такого подхода:

§имеется переносимость;

§небольшой след;

§поведение ОС РВ известно.

Недостатки:

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

49

§нельзя использовать стандартные приложения NT;

§невозможно смешивание с драйверами устройств NT, поэтому весь мир коммуникаций NT недоступен;

§другие драйверы графических устройств и приложения NT невозможно или трудно использовать;

§ограничена возможность расширения в будущем;

§необходимо использовать специальные средства разработки и компиляторы.

Среди коммерческих реализаций этого подхода QNX и VxWorks, использующие библиотеку Windows.

Совместная работа на одном процессоре NT и ОС РВ

Мощность современных процессоров достаточна для одновременного функционирования NT и программ реального времени. Возможны две разновидности такого подхода:

§модификация HAL с перехватом прерываний и включением небольшого диспетчера или ОС РВ;

§выполнение NT, как одной из задач над (супервизором) ОС РВ.

Влюбом случае HAL должен быть модифицирован или по крайней мере перехвачен. В основном все такие решения похожи. В каче

стве иллюстрации можно привести следующее возможное решение с модификацией HAL.

Программу голубого экрана NT можно рассматривать, как упрощенную программу супервизора. Модифицируя ее внутри HAL, можно сделать простой мультизадачный механизм выхода из нее, запустить NT, как одну из задач с самым низким приоритетом и запустить нечто другое, как другую задачу. Это нечто другое может быть набором задач реального времени или полной ОС РВ.

Вобоих случаях необходим механизм связи между частями реального времени и NT. Он может быть выполнен одним из двух способов. Первый заключается во введении альтернативного механизма межпроцессорных связей (IPC). Проще всего реализовать IPC с помощью разделяемой памяти. Недостатком такого протокола IPC является уровень приоритета, на котором выполняются пользовательские приложения NT. При втором способе интерфейс реализуется с

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

50

помощью драйвера устройства, в результате чего у NT создается впечатление, что подсистема реального времени это устройство.

Задачи реального времени используют собственный интерфейс с системой, в большинстве случаев отличный от Win32 API. Среда разработки может быть обычной для используемой ОС РВ средой и может взаимодействовать со средой NT. Задачи реального времени будут выполняться, не получая преимуществ от механизма защиты памяти NT. Особо аккуратно следует продолжать выполнение частей реального времени, когда NT рухнет и сгенерирует голубой экран. След памяти это комбинация следа NT (8 Мбайт в стандартной конфигурации) плюс минимальные требования для части ОС РВ.

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

Преимущества здесь таковы:

§сохранение (почти) всей среды NT нетронутой означает, что все программное обеспечение, устройства и драйверы устройств NT можно использовать (чтобы выполнять части приложения, не связанные с реальным временем). Поддерживается совместимость с NT;

§можно включить защиту для задач реального времени, зависящую от используемой ОС РВ.

Недостатки:

§отсутствует переносимость между реальным временем и средой NT, за исключением случая, когда RT-API разработан на базе Win32;

§драйверы устройств NT нельзя использовать в части реального времени;

§среда разработки усложняется, если для задач реального времени требуется отдельная среда;

§может быть много уровней задач и поэтому много уровней определений контекста. Переключение этих контекстов требует времени.

Известны следующие коммерческие реализации подхода, не требующего модификации аппаратуры: IMAGINATION с HyperKER-

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

51

NEL; RADISYS с комбинацией iRMX/NT; VenturCom с RTX, KPX и RTAPI.

В реализации фирмы RadiSys ОС РВ iRMX работает, как первичная ОС, загружающая Windows NT в качестве низкоприоритетной задачи. Пользователь работает только с NT, не видя и не чувствуя iRMX. Все управляющие функции выполняются, как высокоприоритетные задачи iRMX, изолированные в памяти от приложений и драйверов NT. Используя функции защиты памяти внутри процессора Intel, Windows NT защищена от задач реального времени.

Комбинация iRMX/NT преодолела трудности, которые возникают при модификации HAL и оставляют пользователя уязвимым при сбоях жесткого диска, сбоях драйверов и системных сбоях NT голубой экран смерти«). В этом решении управляющая программа в случае краха NT может либо продолжить нормальное выполнение, либо произвести правильное закрытие системы (shutdown).

Реализация фирмы VenturCom состоит из двух этапов. На первом мягкая реализация RTX 3.1 содержит интерфейс прикладной программы реального времени RTAPI, который дает время реакции 1- 5 мск. RTAPI 1.0 работает со стандартным NT. Единственное изменение, обеспечивающее лучшую синхронизацию событий реального времени, внесено в часы. Так как в Windows NT имеются некоторые плохо предсказуемые процессы, то RTAPI позволит построить только мягкую СРВ с небольшим временем отклика, но недостаточно предсказуемую. Впрочем, большую часть непредсказуемости NT можно устранить, ограничив доступ к системному диску и сети.

Чтобы сделать NT более предсказуемой, необходимо прерывать ее внутренние задачи. В основе второй жесткой реализации RTX 4.1 лежит модификация HAL. В обеспечении детерминизма важную роль играют программируемые часы. В каждый тик часов аппаратное прерывание с регулярными интервалами времени предпочтение отдается задаче реального времени. Оставшееся время предоставляется процессам NT, в том числе и процессам мягкого реального времени. Чем чаще тикают часы, тем больше возможностей у процессора для выполнения задач реального времени. Необходимо добиться баланса между многими факторами: частота тиков, время, выделенное для обработки в реальном времени, время, выделенное для выполнения задач NT.

Использование многопроцессорной архитектуры.

www.pdffactory.com

Соседние файлы в предмете Системы реального времени

  • #
  • #
  • #
  • #
  • #
  • #
  • #

Real-time is the highest priority class available to a process. Therefore, it is different from ‘High’ in that it’s one step greater, and ‘Above Normal’ in that it’s two steps greater.

Similarly, real-time is also a thread priority level.

The process priority class raises or lowers all effective thread priorities in the process and is therefore considered the ‘base priority’.

So, a process has a:

  1. Base process priority class.
  2. Individual thread priorities, offsets of the base priority class.

Since real-time is supposed to be reserved for applications that absolutely must pre-empt other running processes, there is a special security privilege to protect against haphazard use of it. This is defined by the security policy.

In NT6+ (Vista+), use of the Vista Multimedia Class Scheduler is the proper way to achieve real-time operations in what is not a real-time OS. It works, for the most part, though is not perfect since the OS isn’t designed for real-time operations.

Microsoft considers this priority very dangerous, rightly so. No application should use it except in very specialized circumstances, and even then try to limit its use to temporary needs.

Real-time is the highest priority class available to a process. Therefore, it is different from ‘High’ in that it’s one step greater, and ‘Above Normal’ in that it’s two steps greater.

Similarly, real-time is also a thread priority level.

The process priority class raises or lowers all effective thread priorities in the process and is therefore considered the ‘base priority’.

So, a process has a:

  1. Base process priority class.
  2. Individual thread priorities, offsets of the base priority class.

Since real-time is supposed to be reserved for applications that absolutely must pre-empt other running processes, there is a special security privilege to protect against haphazard use of it. This is defined by the security policy.

In NT6+ (Vista+), use of the Vista Multimedia Class Scheduler is the proper way to achieve real-time operations in what is not a real-time OS. It works, for the most part, though is not perfect since the OS isn’t designed for real-time operations.

Microsoft considers this priority very dangerous, rightly so. No application should use it except in very specialized circumstances, and even then try to limit its use to temporary needs.

ВикиЧтение

Системное программирование в среде Windows
Харт Джонсон М

Приоритеты процессов и потоков и планирование выполнения

Приоритеты процессов и потоков и планирование выполнения

Ядро Windows всегда запускает тот из потоков, готовых к выполнению, который обладает наивысшим приоритетом. Поток не является готовым к выполнению, если он находится в состоянии ожидания, приостановлен или блокирован по той или иной причине.

Потоки получают приоритеты на базе классов приоритета своих процессов. Как обсуждалось в главе б, первоначально функцией CreateProcess устанавливаются четыре класса приоритета, каждый из которых имеет базовый приоритет (base priority):

• IDLE_PRIORITY_CLASS, базовый приоритет 4.

• NORMAL_PRIORITY_CLASS, базовый приоритет 9 или 7.

• HIGH_PRIORITY_CLASS, базовый приоритет 13.

• REALTIME_PRIORITY_CLASS, базовый приоритет 24.

Оба предельных класса используются редко, и в большинстве случаев можно обойтись нормальным (normal) классом. Windows NT (все версии) не является ОС реального времени (real-time), чего нельзя сказать, например, о Windows СЕ, и в случаях, аналогичных последнему, классом REALTIME_PRIORITY_CLASS следует пользоваться с осторожностью, чтобы не допустить вытеснения других процессов. Нормальный базовый приоритет равен 9, если фокус ввода с клавиатуры находится в окне; в противном случае этот приоритет равен 7.

Один процесс может изменить или установить свой собственный приоритет или приоритет другого процесса, если это разрешено атрибутами защиты. 

BOOL SetPriorityClass(HANDLE hProcess, DWORD dwPriority)

DWORD GetPriorityClass(HANDLE hProcess)

Приоритеты потоков устанавливаются относительно базового приоритета процесса, и во время создания потока его приоритет устанавливается равным приоритету процесса. Приоритеты потоков могут принимать значения в интервале ±2 относительно базового приоритета процесса. Результирующим пяти значениям приоритета присвоены следующие символические имена:

• THREAD_PRIORITY_LOWEST

• THREAD_PRIORITY_BELOW_NORMAL

• THREAD_PRIORITY_NORMAL

• THREAD_PRIORITY_HIGHEST 

Для установки и выборки относительного приоритета потока следует использовать эти значения. Обратите внимание на использование целых чисел со знаком вместо чисел типа DWORD. 

BOOL SetThreadPriority(HANDLE hThread, int nPriority)

int GetThreadPriority(HANDLE hThread) 

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

• THREAD_PRIORITY_IDLE имеет значение 1 (или 16 — для процессов, выполняющихся в режиме реального времени).

• THREAD_PRIORITY_TIME_CRITICAL имеет значение 15 (или 31 — для процессов, выполняющихся в режиме реального времени).

Приоритеты потоков автоматически изменяются при изменении приоритета процесса. Помимо этого, ОС может регулировать приоритеты потоков динамическим путем на основании поведения потоков. Вы можете активизировать или отключить это средство с помощью функции SetThreadPriorityBoost.

Читайте также

Обработчики завершения: завершение процессов и потоков

Обработчики завершения: завершение процессов и потоков
Обработчики завершения не выполняются, если выполнение процесса или потока было прекращено независимо от того, было ли это инициировано самим процессом путем использования функций ExitProcess или ExitThread, или вызвано

ГЛАВА 7 Потоки и планирование выполнения

ГЛАВА 7
Потоки и планирование выполнения
Основной единицей выполнения в Windows является поток, и одновременно несколько потоков могут выполняться в рамках одного процесса, разделяя его адресное пространство и другие ресурсы. В главе 6 процессы ограничивались только одним

Предостережение относительно использования приоритетов потоков и процессов

Предостережение относительно использования приоритетов потоков и процессов
Высокими приоритетами потоков и высокими классами приоритета процессов необходимо пользоваться с осторожностью. Следует решительно избегать использования приоритетов реального времени для

Безопасная отмена выполнения потоков

Безопасная отмена выполнения потоков
Обсуждение предыдущего примера продемонстрировало, как безопасно отменить выполнение целевого потока, который использует состояния дежурного ожидания. Несмотря на использование АРС, такую отмену выполнения иногда называют

Стеки потоков и допустимые количества потоков

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

Глава 4 Планирование выполнения процессов

Глава 4
Планирование выполнения процессов
В предыдущей главе были рассмотрены процессы — абстракция операционной системы, связанная с активным программным кодом. В этой главе представлен планировщик процессов — код, который позволяет процессам

Планирование выполнения процессов

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

8.1 ПЛАНИРОВАНИЕ ВЫПОЛНЕНИЯ ПРОЦЕССОВ

8.1 ПЛАНИРОВАНИЕ ВЫПОЛНЕНИЯ ПРОЦЕССОВ
Планировщик процессов в системе UNIX принадлежит к общему классу планировщиков, работающих по принципу «карусели с многоуровневой обратной связью». В соответствии с этим принципом ядро предоставляет процессу ресурсы ЦП на квант

Приоритеты прерываний и процессов первого плана

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

8.5. Отмена выполнения потоков

8.5. Отмена выполнения потоков
Обсуждая листинг 8.4, мы обратили внимание на наличие проблемы, возникающей при отмене выполнения потока, заблокированного вызовом pthread_cond_wait. Выполнение потока может быть отменено в том случае, если какой-нибудь другой поток вызовет функцию

Взаимосвязь процессов, доменов приложений, контекстов и потоков

Взаимосвязь процессов, доменов приложений, контекстов и потоков
В предыдущей главе обсуждалось понятие потока, который был определен, как путь исполнения в рамках выполняемого приложения. И хотя многие приложения .NET имеют только один поток и, тем не менее, оказываются

Приоритеты

Приоритеты
     Операция ! имеет очень высокий приоритет, он выше, чем у умножения, такой же, как у операций увеличения, и только круглые скобки имеют более высокий приоритет. Приоритет операции && больше чем операции ||, а обе они имеют более низкий приоритет, чем

2.2.1.3 Планирование потоков

2.2.1.3 Планирование потоков
Сервер осведомлен о степени значимости различных потоков и в соответствии с этим назначает для них приоритеты. Например, потоки ввода-вывода получают приоритеты следующим образом: 1. ввод-вывод логической журнализации — наивысший приоритет;2.

3.2.3. Планирование процессов

3.2.3. Планирование процессов
Операционная система Linux планирует работу родительских и дочерних процессов независимо друг от друга. Нет гарантии, что один процесс будет запущен раньше другого. и неизвестно, как долго один процесс будет выполняться, прежде чем Linux прервет

4.6. Сравнение процессов и потоков

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

Понравилась статья? Поделить с друзьями:
  • Потоки в диспетчере задач windows 10
  • Поток портала авторизации windows 10 что это
  • Потеряются ли файлы при обновлении windows 10
  • Потеряются ли данные при переустановке windows 11
  • Потерялся значок мой компьютер windows 10