Блог

Главная - Вопросы по программированию - Как Java реального времени избегает инверсии приоритета

Как Java реального времени избегает инверсии приоритета

#java #real-time

#java #в реальном времени

Вопрос:

Спецификация реального времени для Java указывает, что она предлагает инструменты для работы со случаями инверсии приоритета, такие как протоколы наследования приоритета и ограничения приоритета.

В POSIX есть pthread_mutexattr_getprotocol , который может установить протокол, используемый для решения этой проблемы 

 PTHREAD_PRIO_NONE
PTHREAD_PRIO_INHERIT  //(PIP)
PTHREAD_PRIO_PROTECT  //(PCP)

Мне интересно, эквивалентно ли это Java в реальном времени.

Спасибо.

Комментарии:

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

2. Не могли бы вы подробнее рассказать об этом, пожалуйста? Знакомы ли вы с WaitFreeReadQueue объектами и тому подобным?

3. Похоже, это обеспечивает ту же функциональность, что и Queue.poll() и BlockingQueue.take(). Некоторые функциональные возможности, которые были только в RTSJ, были добавлены в OpenJDK на протяжении многих лет. 😉 Лично я избегаю использования очередей для минимизации мусора (поскольку вам нужно передавать объекты, а очереди не перерабатывают свои объекты) Вместо этого я использую ByteBuffers, использую Pipe или Exchanger.

Ответ №1:

Для поддержки, по крайней мере, наследования приоритета требуются реализации, совместимые с RTSJ; ограничение приоритета необязательно. IBM WebSphere Real Time, например, поддерживает наследование приоритетов и полагается на операционную систему, обеспечивающую наследование приоритетов для всех блокировок Java (что означает, что с любым заблокированным объектом всегда связан мьютекс pthread, хотя у нас все еще есть способы сделать это быстрее, чем это могло бы показаться в противном случае, особенно для блокировок, которые на самом деле не оспариваются). Спин-блокировки, которые традиционные JVM не реального времени, как правило, используют для ускорения кратковременных блокировок, не могут использоваться в JVM реального времени, потому что они создают проблемы с блокировкой, когда у вас потоки, запущенные с разными уровнями приоритета (во всяком случае, для политик SCHED_RR / SCHED_FIFO, где более высокий уровень приоритета вытесняет, точка).