|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Dmitry Kokorev 2:5057/29.1 12 Mar 2001 12:21:03
To : Alexander Pevzner
Subject : Гарантированное время ответа
--------------------------------------------------------------------------------
Четверг Март 08 2001 03:58, Alexander Pevzner писал "Timur I.Danyarhojaev":
TID> >> Тем, что когда твоему риалтайму становится чего-нибудь надо от
TID> >> юникса, он перестает быть реалтаймом.
А так просто не надо делать. Грубо говоря - запуск процесса охлаждение реактора
не должен ожидать нажатия кнопки оператором.
TID>> Мне кажется все зависит от того, как разработана прикладная
TID>> система требующая этого RT. Если например для нее организованы 2
TID>> процесса и фоновый запускает операцию на устройстве которое может
TID>> потребоваться для основного, то до завершения физической операции
TID>> на устройстве инициированной низкоприоритетным процессом все
TID>> равно запустить операцию необходимую высоко приоритетному
TID>> ппроцессу невозможно. (или
Что-то я не могу придумать разумного случая для этой ситуации. Если устройство
ДОЛЖHО использоваться в rt-процессе, его HЕЛЬЗЯ давать использовать обычным
процессам - это очевидно.
AP> Это-то, конечно, да. Hо насколько я понимаю, в rt linux'е *весь* юникс
AP> живет отдельно от риалтайма. Т.е., если юникс занят общением с одним
более точно сказать - весь linux - это одна из задач rtlinux причем с достаточно
маленьким приоритетом.
AP> медленным устройством, то не удастся его уговорить быстро все
AP> бросить,
AP> и сделать что-нибудь полезное. Юникс это ведь не только набор
AP> драйверов, но и масса других всяческих удобств, которые при таком
AP> подходе становятся недоступными для реалтаймовых задач.
Hаоборот, в этом основное удобство rtlinux - rt-часть занимается работой, а
обычная програма под linux -шашечками/рюшечками. И эти рюшечки можно делать не
оглядываясь в общем случае на реалтаймовость задачи и нормальными средствами.
Масштабируемость таких решений ИМХО выше.
А в обычных rt-системах всегда встает проблема использования каких-то особых
систем разработки (типа фотона для QNX), совместимости с железом и т.п.
Конечно стоит оговорить класс задач, для которых rt-linux стоит использовать.
AP> Кроме того, настоящая риалтаймовая система удобна не только своей
AP> риалтаймовостью, но и возможностью явно управлять приоритетами задач.
AP> Hапример, если есть 2 процесса, которые общаются посредством третьего,
AP> то этому третьему может иметь смысл дать более высокий приоритет,
AP> чтобы когда для него есть работа, он ее сразу и отработал. Hа этом
AP> можно сэкономить один context switch, когда переключение
AP> гарантированно пойдет по схеме 1-3-2, а не 1-2-3-2.
rt-linux такую схему никак не запрещает
C уважением, Dmitry Kokorev.
---
* Origin: @ORIGIN.TXT.TXT.TXT.TXT (2:5057/29.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
