Начать хочу с благодарности Антону, который открыл тему и сформулировал очень сложные вопросы ответы на некоторые из которых (на многие, как мне кажется) мне представляются очевидными, хотя и объемными в изложении в соответствии с этой своей сложностью. Собственно, я и хочу изложить эти ответы и продемонстрировать их очевидность, а также откуда берется и с чем связана указанная сложность, которая трансформируется в объем и как и почему она в него трансформируется.
Исходная статья лежит здесь
Очень интересно и очень грустно наблюдать как люди, которые, например, не могут спроектировать надежную схему (из моего опыта): прерываний для совместной работы, например,
системы управления автоматической системой усиления на основе измерения мощности по периодическим прерываниям АЦП и выводом рассчитанного коэффициента в ЦАП на фоне постоянного статусного-управляющего обмена по последовательной шине,
эти люди рассуждают о необходимости использования ОСРВ для такого рода задач. Выглядит как: вроде как мы не умеем пользоваться своими мозгами, но вот если нам выдадут искусственный интеллект, вот мы его научим задачи решать!
Еще очень впечатляют и восхищают вот такие заявления:
«Вы путаете Embedded OS и RTOS, между ними нет строгого знака равенства. Отсюда и весь посыл статьи заведомо ошибочен.»
Хочется спросить, а вы на какие определения того и другого опираетесь, а вы уверены, что они придуманы не для того, чтобы их путать? Ведь если между ними нет строгого знака равенства, это значит между ними есть НЕ строгий знак равенства. А раз есть хоть какой-то знак равенства то почему же их не спутать? Получается заявление противоречит само себе: утверждает, что они очень похожи, но запрещает их путать. Заявление достойно какой то блондинки, а блондинки всегда у меня вызывают восхищение :) .
Про термины и их определения
Дело в том, что термины всегда вводятся с какой-то целью и самая естественная цель — это сократить объем документации в которой используется термин за счет того, что не надо повторять разные составляющие определения этого термина. Я думаю (наверно даже знаю) ОСРВ это что-то гораздо больше термина который предполагается использовать в таких целях. ОСРВ скорее тянет на название стандарта, описывающего такой тип Операционных Систем или ... на термин из области маркетинга, цель которого просто обратить внимание – выделить позиционируемый под таким названием продукт, воспользоваться модным названием, полное значение которого надо неделю изучать по иностранным (поскольку отечественных не существует), а значит малодоступные стандартам. Поэтому строгого определения, скажем на пол страницы, для ОСРВ не существует, существуют стандарты, которые определяют такое понятие страниц на 10-50-100, я не проверял. Причем какой-нибудь медицинский стандарт по этому поводу может быть совершенно не согласованным с подобным авиационным стандартом.
Multimedia systems некоторые определяют как SOFT системы реального времени
Теперь давайте вернемся к провокационному вопросу в заголовке, Windows тоже RTOS? Конечно, одна из целей такого провокационного вопроса в заголовке привлечь внимание к статье (иначе зачем я ее пишу, если не надеюсь на интерес аудитории!)
Но если мы считаем, что некоторая ОС НЕ является системой реального времени, мы должны уметь показать это, привести хоть какие-то аргументы что бы обосновать это.
Для того чтобы сформулировать определение для ОСРВ неплохо бы рассмотреть некоторую задачу реального времени. Проблема в том что в большинстве своем задачи реального времени очень специфичные и не подходят как пример для всех, потому что сама формулировка задачи обычно вызывает непримиримые дискуссии.
Кстати, ОСРВ можно в общем определить таким образом: Операционной Системой Реального Времени является ОС, которая позволяет решать задачи реального времени. Я думаю, поиск ОСРВ всегда начинается только при наличии соответствующей задачи, поэтому это вполне логичное определение. Соответственно при наличии вариантов встает вопрос об эффективности решения данной задачи в разных системах, вопрос о критериях оценки этой эффективности. А вся дискуссия про реальное время уходит в область определения задач.
По поводу предлагаемой к рассмотрению задачи: я с удивлением нашел у Антона в статье что в иностранной практике multimedia systems тоже рассматриваются как системы реального времени:
Another kind of real-time system is a soft real-time system, in which missing an occasional deadline, while not desirable, is acceptable and does not cause any permanent damage. Digital audio or multimedia systems fall in this category. Digital telephones are also soft real-time systems.
Я одно время очень плотно и успешно работал над этой всем известной задачей, которая, как, надеюсь будет видно из моего опыта, очень близка (как минимум) к задачам реального времени, это задача декодирования-проигрывания видео. Не все осознают, что цель этой задачи именно управление «железом»: устройствами отображения и воспроизведения звука именно в реальном времени, хотя, по-моему, это очевидно. Задача задает четкие требования по времени отображения очередного кадра и синхронизации отображения кадров со звуком. Если у вас кино записано с частотой, скажем, 25 (а бывает и 50, и 60) кадров в секунду, это значит у вас есть 1000/25 = 40 мс чтобы:
прочитать данные из файла (из источника данных)
разделить потоки видео и аудио
декодировать аудио фрейм
декодировать достаточно аудио данных
записать видео данные в аппаратный буфер отображающего устройства (циркулярный буфер фреймов видеокарты)
записать аудио данные в аппаратный циркулярный буфер звукового устройства (вовремя записать!)
в нужный момент, в соответствии с периодом (40 мс) дать команду видеокарте на переключение отображаемого фрейма
Я специально привел здесь этот список что бы показать, что задача и последовательность необходимых операций далеко не тривиальные, для того, чтобы впихнуть их в какие то 40 мс, причем впихнуть не единожды, а на протяжении часов поддерживать этот интервал, соблюдая последовательность операций которая не может быть нарушена.
Относительно «вовремя записать», можно отметить, что аудио буферу не нужна команда что бы он проиграл очередную порцию сэмплов, но надо следить что бы у него не кончились данные или чтобы он не перешел в зону не переписанных данных (контролировать overflow или underflow). Не менее сложной задачей при реализации видео плеера является синхронизация звука и видео, потому что уже при задержке в пол секунды между ними смотреть кино становится неприятно (как минимум).
Еще для справки, очень среднего разрешения кино имеет фрейм размером 640 х 480 = 307 200 х 4 байта для передачи цвета = 1,228,800 байт – больше Мега байта данных надо пересылать в видео буфер каждые 40 мс, это уже не какая то мгновенная операция копирования, потом надо еще учитывать задержку аппаратуры, копируем, все таки, в аппаратный буфер.
У нас для задачи четко определен интервал времени, который должен быть выдержан для того, чтобы работа программы реализующей задачу была успешной, но с какой точностью мы должны выдерживать этот интервал? Какие отклонения от среднего допустимы, 5 мс, 10 мс, ... можно позволить? Как это выбрать?
Как не странно это звучит у человеческого глаза тоже есть технические характеристики :) , мы не замечаем пульсации света примерно меньше 1/7 секунды, собственно отсюда и взялись 25 кадров в секунду – это с запасом для особо чувствительных. Получается, что можно в принципе даже один фрейм иногда пропустить если получится сделать это так, что программа при этом не упадет (для тех, кто понимает сложность реализации такой фичи).
Почему эта задача как минимум, очень близка к задачам реального времени? Вроде как очевидно: программа, реализующая эту задачу, должна достаточно жестко контролировать время своих обращений к аппаратным модулям, она должна формировать И контролировать корректную схему всех необходимых операций по времени (мне, например, приходилось рисовать схему взаимодействия потоков для своей реализации). И, кстати, для тех, кто считает, что человек и реальное время понятия несовместимые, рассматриваемая задача должна выполняться не просто в реальном времени а в человеческом реальном времени, потому что результат ее выполнения жестко связан с физиологическими особенностями восприятия времени и событий в нем человека.
Что же в этом сложного? Дело в том, что чтобы измерять время нужно время! И это не тавтология — это рефлексия, это замкнутый круг, в который тем не менее надо в начале корректно войти, корректно отсчитывать периоды, и в конце корректно выйти.
А где же катастрофа? или критерий критичности задачи
Но, конечно, есть очень важный аспект, по которому эта задача не будет принята к рассмотрению большинством аудитории как задача реального времени, это критичность или фатальность последствий отказа или сбоя в реализации, ну подумаешь кино квадратиками пошло или зависло на перекошенной физиономии.
Но представьте, что вы занимаетесь техническим обеспечением трансляции важного выступления уважаемого руководителя в очередном 37 году. Задача станет не только задачей реального времени во всех смыслах этого словосочетания, задача станет задачей фатальной ответственности. Таким образом, можно видеть, что критичность задачи - параметр достаточно условный, и я бы даже сказал очень субъективный – то что для одного будет безделицей для другого легко может стать трагедией и катастрофой. Вряд ли можно ориентироваться на такой субъективный параметр в технических вопросах, задачу в любом случае надо решать надежно и эффективно. А если есть задача ее решение должно обеспечить стабильность и эффективность использования системных и аппаратных ресурсов.
Про Операционную Систему саму по себе
Рассматривая понятие Операционная Система Реального Времени было бы странно не определить общее понятие Операционная Система. Если ваши доводы в обсуждении не основываются на известном определении для Операционной Системы скорее всего вы хотите запутать оппонента или задавить его авторитетом.
Как говорил Мюллер Штирлицу: «Никому нельзя верить, Мне можно!», но в данном случае мне можно верить, потому что я начинаю с определения.
Так вот можно попробовать сформулировать что такое Операционная Система (ОС) вообще. Мне нравится мое определение (не только по понятной причине, но и по тому к каким очевидным выводам оно ведет):
ОС — это программа, которая определяет доступные пользователю операции из расширяемого списка, для примера:
открыть-запустить на исполнение файл
все операции с файлами: копировать, удалить, ...
Создать/удалить поток (thread)
Создать/удалить семафор
Стандартные операции ввода в стандартной консоли или все возможные операции с окнами
Поддержка операций copy/past между исполняемыми модулями (поверьте имеет очень интересную реализацию на системном уровне)
Удалите все что вам не нравится
Добавьте свое
с сущностями, которые определены в этой ОС для операций пользователем или исполняемым модулем из расширяемого списка, для примера:
Файлы данных
Файлы исполняемые (я, и многие я думаю, знают примеры ОС которые не работают с файлами)
Файлы библиотек (статических, динамических)
Устройства и их программы обслуживания-доступа, известные как драйвера,
Семафоры, потоки, мутексы, ...
Задачи, процессы, исполняемые модули (исполняемые в данный момент, либо в любом другом состоянии из списка состояний определенным данной ОС, опять же!)
Консоли, Окна, любые объекты для визуального взаимодействия с ОС
Удалите все что вам не нравится
Добавьте свое
Мы видим, что при определении ОС нам тоже не обойтись без рефлексии. ОС определяется тем, что сама эта ОС может делать, и тем, что она определяет как управляемые сущности в рамках себя самой!
Если мы вводим какое-то уточненное название как Real Time ОС понятно, что мы должны уточнить это общее определение для просто ОС.
Что же мы можем уточнить в общем определении ОС что бы было понятно, что имеется в виду именно РТОС? По-моему, совершенно очевидно: мы должны внести в расширяемый список операций тот набор обязательных операций, которые должна поддерживать РТОС!!!
Почему-то никто даже не пытается посмотреть на Операционную Систему с точки зрения вот этих самых операций, для которых она и есть система, система с операциями, система в которой существуют(живут) операции!
Как же добиться характеристик реального времени (или универсальность математики)
Такой интересный заголовок (без добавки) есть у Антона в статье.
Я думаю, Антон хотел сказать что-то вроде:
Так чем же все-таки определяется принадлежность ОС к разряду Операционных Систем реального времени?
И предлагается ответ, с которым трудно не согласиться: «Это время и предсказуемость.»
Единственное, мне кажется тут следует дополнить или где-то даже поправить это заключение.
Принадлежность к ОСРВ определяется все-таки не просто временем (временем чего?), а предоставленной системой возможностью контролировать время:
измерять время
задавать периоды
назначать время событий, исполнения процедур, ... - чего угодно из того, что определено в ОС (см. список сущностей ОС)
И очень интересно получается с предсказуемостью:
Предсказуемость не является характеристикой подлежащей численной оценке, надо найти характеристику, которая дает численную характеристику предсказуемости и такая характеристика, конечно, есть – математика универсальна.
Покажем, что предсказуемость считается через разрешение по времени (кстати тут опять рефлексия или как это здесь называется? Разрешение по времени — это производная величина от времени которая имеет размерность времени).
Поясню на примере: если мы задаем время некоторого события скажем в мили секундах как Т мс от текущего времени мы можем ожидать что:
Событие произойдет через время Treal такое что Т <= Treal < (T+1 МИЛЛИ секунда), то есть в этом случае мы исходим из того что разрешение по времени которое обеспечивает нам система это 1 мили секунда!
Но ведь вполне может оказаться что Т <= Treal < (T+1 МИКРО секунда), так как система обеспечивает нам разрешение по времени в МИКРО секундах. Никто же не может запретить нам использовать миллисекунды если можно использовать ДАЖЕ микросекунды!
Я думаю, всем понятно, что предсказуемость момента события в течение 1 мкс в 1000 раз выше, чем предсказуемость момента события в течение миллисекунды.
Из этого примера видно, что предсказуемость — это не абсолютная величина – это величина отношения разрешений по времени! Предсказуемость момента события в первой системе в 1000 раз меньше, чем предсказуемость момента события во второй системе и зависит это от разного разрешения по времени которое обеспечивают эти две системы, точнее от отношения этих разрешений.
Так вот, можно в общем определенно сказать, что Операционная Система Реального Времени — это ОС, в которой существуют все необходимые операции по контролю и управлению временем. И, ограниченно максимальное разрешение по времени для определяемых в системе интервалов времени.
P.S.
Конечно, можно продолжить рассуждать дальше и описать другие интересные выводы о том, как в этом всем участвуют характеристики аппаратной платформы базирования, например. Но мне хотелось бы посмотреть сначала найдутся ли те, которые дочитают до универсальной математики эту статью.
