-
Уверен, здесь есть люди, которые знают ответ на вопрос, который я никак не могу понять про т.н. "ОС реального времени". Чтение документации и интернета мне тоже никак не помогает.
На сколько я сумел понять, суть "ОС реального времени" в том, что они гарантируют, что после того, как случился какой-то (аппаратный) сигнал и началом выполнения соответствующего ему обработчика (программного кода) пройдёт не более некоего оговоренного отрезка времени.
Но вот на какой вопрос я никак не могу найти ответ: а как-то ограничивается сверху или наоборот или гарантируется минимальное время выполнения вызванного кода?
Подскажите, пожалуйста, кто знает.
-
Гарантируется тем, что выполняется только один поток.
-
В самом деле:
Пусть сработал датчик, в ответ на это запустился код запуска мотора, например.
Вполне возможно, что запустить мотор - это в каком-то конкретном случае условно 5 секунд и все эти 5 секунд надо выполнять код запуска (пусть такие требования).
Но ведь тогда нам, очевидно, не удастся отреагировать, например, за 1 мс на другой сигнал, потому что выполняется код запуска двигателя.
Либо мы должны буем прервать код запуска двигателя, чтобы выполнить условия гарантированного времени реакции - но тогда мы потеряем контроль за запускаемым двигателем, очевидно.
И вот эту нестыковку я никак не могу понять в описаниях ОС реального времени.
Понятно, что моно сказать "ну так уменьшай время выполнения кода запуска", но тогда получается есть какие-то требования к максимальному времени выполнения обработчиков, но про это мне не удалось найти каких-либо упоминаний.
Ну и потом, если обработчиков сработавших много - то сколь бы быстро они не работали процессора (любого) может не хватить, чтобы успеть выполнить все обработчики. Видимо есть еще какие-то требования к производительности и количеству обработчиков? но про это тоже мне не попадалось какой-то информации. Или я невнимательно читал?
-
Чё это они однопоточные вдруг обязательно должны быть?
Видимо, ОС генерирует исключение что-то типа обработчик_события_превысил_выделенную_ему_квоту. Далее надо что-то с этим сделать в программе.
-
> KSergey © (24.08.17 09:42) [2]
Решение от задачи зависит. Я думаю задачи очень узкие у таких систем иначе никакой гарантии.
-
> а как-то ограничивается сверху или наоборот или гарантируется
> минимальное время выполнения вызванного кода?
Не понимаю вопроса, возможно, пример будет уместен. ОС реального времени вполне может быть многопоточной.
-
> Игорь Шевченко © (24.08.17 10:25) [5]
> Не понимаю вопроса, возможно, пример будет уместен. ОС реального
> времени вполне может быть многопоточной.
Многопоточность - ресурс не бесконечный.
Положим, все доступные потоки (ядра) уже выполняют какие-то обработчики. Приходит новый сигнал, для которого ОС реального времени по идее гарантирует время реакции.
И что ей делать? обработчики того же приоритета уже работают, запустить новый обработчик просто негде, а гарантированный тайм-аут на запуск истекает.
Как в этих условиях гарантируется обеспечение времени запуска кода обработчика?
Или это какие-то заграничные условия, про которые обычно не рассказывают? или рассказывают, но я не вижу ключевые слова?
-
> Inovet © (24.08.17 09:46) [3]
> Видимо, ОС генерирует исключение что-то типа _бработчик_события_превысил_выделенную_ему_квоту.
> Далее надо что-то с этим сделать в программе.
Тогда, выходит, для таких ОС есть прописанное ограничение на длительность выполнения обработчиков. Но мне не попадалось про это, что, собственно, и не понятно.
-
> [6] KSergey © (24.08.17 10:43)
> Как в этих условиях гарантируется обеспечение времени запуска кода обработчика?
> [7] KSergey © (24.08.17 10:46)
> Тогда, выходит, для таких ОС есть прописанное ограничение на длительность выполнения обработчиков.
Раз это многопоточная ОС, то так же как и в Виндоус, только более жёсткие требования, т.е. обработчик будет запущен с известной задержкой.
В ОС РВ предполагается некоторое конечное заранее известное количество работающих задач. В конкретной реализации обслуживания заранее тестируется их работа, в том числе и критических ситуациях. Так что ресурсов времени должно хватать и быть с некоторым запасом. Нештатная ситуация означает либо аварию с отказом оборудования, либо возможное предусмотренное развитие ситуации. В обоих случаях должна быть заранее предусмотренная отдельная обработка.
Длительность выполнения тоже должна задаваться для каждого обработчика. Ну а как иначе.
-
> Положим, все доступные потоки (ядра) уже выполняют какие-
> то обработчики. Приходит новый сигнал, для которого ОС реального
> времени по идее гарантирует время реакции.
> И что ей делать? обработчики того же приоритета уже работают,
> запустить новый обработчик просто негде, а гарантированный
> тайм-аут на запуск истекает.
Это фантазии.
При проектировании подобных систем учитывают реальные сигналы (они обычно не спонтанно приходят), кроме времени гарантированой обработки еще в таких системах есть понятие качества обслуживания (как пример - мультимедиа системы обработки видео, где пропуск небольшой части кадров не повлияет на результат), поэтому приведенных ситуаций (когда все занято обработкой и вдруг приходит что-то еще) не случается.
-
-
> Игорь Шевченко © (24.08.17 11:55) [9]
Не понял немного
А как определяется, что важно пропустить, а что нет?
Пару десятков кадров - наверное, но +-20 метров ракеты, наверное, не очень..
-
> [11] ВладОшин © (24.08.17 15:56)
> но +-20 метров ракеты, наверное, не очень..
Для ракеты и требования к качеству обслуживания другие, чем для массового вещания видео.
-
-
> Игорь Шевченко © (24.08.17 11:55) [9]
> Это фантазии.
Но ведь дальнейший твой текст говорит о том, что это не фантазии, а реальность, коль скоро это учитывают и не допускаю, правда ведь? ;)
> При проектировании подобных систем учитывают
Т.е., если я верно всё понял, понятия "гарантированное время работы обработчика" никто не вводит и параметр такой не нормирует.
Однако, при разработке в целом системы реального времени, опираясь на известные характеристика сигналов (грубо говоря частоту их появления), проектировщик обязан так писать код и выбрать такое железо, чтобы описанного сценария "всё занято, обрабатывать сигнал не на чем" просто не случалось.
Верно я понял?
-
> Eraser © (24.08.17 16:18) [13]
> самая первая ссылка в выдаче.
> очень доходчиво все описано
Можно конкретную цитату, отвечающую на мой вопрос?
-
KSergey © (24.08.17 16:26) [14]
> Но ведь дальнейший твой текст говорит о том, что это не
> фантазии, а реальность, коль скоро это учитывают и не допускаю,
> правда ведь? ;)
Неправда.
> "гарантированное время работы обработчика" никто не вводит
> и параметр такой не нормирует
Вводят и нормируют.
-
> KSergey © (24.08.17 16:27) [15]
Работа планировщика
Большинство ОСРВ выполняет планирование задач, руководствуясь следующей схемой[7]. Каждой задаче в приложении ставится в соответствие некоторый приоритет. Чем больше приоритет, тем выше должна быть реактивность задачи. Высокая реактивность достигается путём реализации подхода приоритетного вытесняющего планирования (preemptive priority scheduling), суть которого заключается в том, что планировщику разрешается останавливать выполнение любой задачи в произвольный момент времени, если установлено, что другая задача должна быть запущена незамедлительно.
Описанная схема работает по следующему правилу: если две задачи одновременно готовы к запуску, но первая обладает высоким приоритетом, а вторая — низким, то планировщик отдаст предпочтение первой. Вторая задача будет запущена только после того, как завершит свою работу первая.
Возможна ситуация, когда задача с низким приоритетом уже запущена, а планировщик получает сообщение, что другая задача с более высоким приоритетом готова к запуску. Причиной этому может послужить какое-либо внешнее воздействие (прерывание от оборудования), как, например, изменение состояния переключателя устройства, управляемого ОСРВ. В такой ситуации планировщик задач поведет себя согласно подходу приоритетного вытесняющего планирования следующим образом. Задаче с низким приоритетом будет позволено выполнить до конца текущую машинную команду (но не команду, описанную в исходнике программы языком высокого уровня), после чего выполнение задачи приостанавливается[7]. Далее запускается задача с высоким приоритетом. После того, как она прорабатывает, планировщик запускает прерванную первую задачу с машинной команды, следующей за последней выполненной.
Каждый раз, когда планировщик задач получает сигнал о наступлении некоторого внешнего события (триггер), причина которого может быть как аппаратная, так и программная, он действует по следующему алгоритму[7]:
Определяет, должна ли текущая выполняемая задача продолжать работать.
Устанавливает, какая задача должна запускаться следующей.
Сохраняет контекст остановленной задачи (чтобы она потом возобновила работу с места остановки).
Устанавливает контекст для следующей задачи.
Запускает эту задачу.
Эти пять шагов алгоритма также называются переключением задач.
-
Походу тут народ в ОСРВ совсем не разбирается. Лучше задайте этот вопрос на electronix.ru
Мои архивы сейчас на другом компе. Поэтому отвечаю по памяти.
Так вот на данный момент существует два типа ОС РВ.
ОС РВ - первого поколения в последствии переименованные в ОСЖРВ.
И ОС РВ - второго поколения. Так же именуемые ОСРВ
В чём отличия? В первых всё просчитана до такта и использован доказательный подход к проектированию.
Вторые чисто маркетинговые и вместо строгих просчётов используются замеры производительности (профалинг, estimetion).
Что такое ОС ? ОС это совокупность программ. Которые взаимодействуют между собой. Но тут встаёт вопрос что будет если вы решите написать свою программу? Вы измените связи между частями ОС! Это что получается что ОС РВ перестанет быть ОС РВ? И да и нет. Это означает что о реальном времени теперь должны заботиться Вы. Вы должны наложить ограничение сверху на задачу. И сделать допуск на отклонение от нормы.
Вы должны про суммировать все все времена потраченные на отдельные функции и рассчитать что квант необходимой для одной задачи.
Но помимо вашей программы есть ещё и внешняя среда? Она ведь не рассчитана на реальное время. Получается что наша система вообще не может быть ОСРВ?
Сразу скажу что нет. Для этого просто посмотрим на ПЛКА. Что мы имеем? А имеем мы 3-х уровневую структуру. Верхняя АСУ. Второй уровень мониторы операторов и третий уровень сами ПЛКА и железо.
Так вот ПЛКА и железо общаются между собой по шинам специально спроектированным для работы в реальном времени. А вот операторские мониторы не путать с пультами. Пульт оператора так же работает в реальном времени. А вот монитор не обязан. Так вот в этом ПЛКА крутиться ОСРВ. И доступ к линиям которые не обязаны работать в реальном времени происходят через особенные точки доступа. в которых осуществляется контроль за соблюдением времени.
Тем самым мы получаем, что сигналы не могут поступить хаотично. Они поступают к нам в заранее оговорённое время. А вот те участки которые работают в нереальном времени обрабатываются как второстепенные задачи. И проверка такого сигнала идёт не по прерыванию, а периодически в цикле или по таймеру.
Информация собраны из нескольких старинных книг по ОС. В интернете ничего подобного не видел.
Подробнее про точки сопряжения читать в книга про язык АДА.
-
Описался малость вместо ПЛКА - следует везде ПЛК
-
> KSergey © (24.08.17 09:36)
>
> Уверен, здесь есть люди, которые знают ответ на вопрос,
> который я никак не могу понять про т.н. "ОС реального времени".
> Чтение документации и интернета мне тоже никак не помогает.
>
>
> На сколько я сумел понять, суть "ОС реального времени" в
> том, что они гарантируют, что после того, как случился какой-
> то (аппаратный) сигнал и началом выполнения соответствующего
> ему обработчика (программного кода) пройдёт не более некоего
> оговоренного отрезка времени.
>
> Но вот на какой вопрос я никак не могу найти ответ: а как-
> то ограничивается сверху или наоборот или гарантируется
> минимальное время выполнения вызванного кода?
В общем случае ничего не гарантируется и ничего не ограничивается, кроме возможностей современной электроники.
Но я так понял, что тебя интересует вовсе не задача X, а скорее задача Y.
-
>>В общем случае ничего не гарантируется и ничего не ограничивается,
"Realtime OS" это в общем случае оксюморон. Например в задачах связанных с промышленностью по прежнему используют FPGA/PRU/DSP/ОС работающие в не защищенном режиме без поддержки вирт памяти/. Любое переключение контекста потока уже убивает сам принцип RTOS, если конечно оно не быстрее обработки прерываний от аппаратуры.
|
Есть новые 
Нет новых [134430 +2][b:0][p:0.001]