Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску

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

ICPP против OCPP [ править ]

Есть два варианта протокола: Оригинал потолочного Priority протокол ( OCPP ) и Immediate потолочного Priority протокол ( ICPP ). Наихудшее поведение двух схем потолка идентично с точки зрения планирования. Оба варианта работают за счет временного повышения приоритета задач. [2]

В OCPP приоритет задачи X повышается, когда задача Y с более высоким приоритетом пытается получить ресурс, заблокированный X. Затем приоритет задачи повышается до верхнего предела приоритета ресурса, гарантируя, что задача X быстро завершит свой критический раздел, разблокировав ресурс. Задаче разрешается блокировать ресурс только в том случае, если ее динамический приоритет выше, чем потолочные значения приоритета всех ресурсов, заблокированных другими задачами. В противном случае задача будет заблокирована в ожидании ресурса. [2]

В ICPP приоритет задачи сразу же повышается, когда она блокирует ресурс. Приоритет задачи устанавливается равным потолку приоритета ресурса, поэтому ни одна задача, которая может заблокировать ресурс, не может быть запланирована. Это гарантирует свойство OCPP: «Задача может заблокировать ресурс только в том случае, если его динамический приоритет выше, чем предельные значения приоритета всех ресурсов, заблокированных другими задачами». [2]

  • ICPP легче реализовать, чем OCPP, так как блокирующие отношения не нужно отслеживать [2]
  • ICPP приводит к меньшему количеству переключений контекста, поскольку блокировка происходит до первого выполнения [2]
  • ICPP требует более приоритетных перемещений, поскольку это происходит при использовании всех ресурсов [2]
  • OCPP меняет приоритет только в том случае, если произошла фактическая блокировка [2]

ICPP называется «блокировкой потолка» в Ada , «протоколом защиты приоритета» в POSIX и « эмуляцией потолка приоритета» в RTSJ . [3] Он также известен как «протокол высочайшего приоритета локера» (HLP). [4]

См. Также [ править ]

Ссылки [ править ]

  1. ^ Ренвик, Кайл; Ренвик, Билл (18 мая 2004 г.). «Как пользоваться наследованием приоритета» . embedded.com . Проверено 11 ноября 2014 года .
  2. ^ a b c d e f g «Архивная копия» (PDF) . Архивировано из оригинального (PDF) 13 ноября 2014 года . Проверено 13 ноября 2014 . CS1 maint: заархивированная копия как заголовок ( ссылка )
  3. ^ Алан Бернс ; Энди Веллингс (март 2001 г.). Системы реального времени и языки программирования - Ada 95, Java в реальном времени и POSIX в реальном времени (3-е изд.). Эддисон Уэсли Лонгмейн. ISBN 0-201-72988-1.
  4. ^ http://user.it.uu.se/~yi/courses/rts/dvp-rts-08/notes/synchronization-resource-sharing.pdf