Какие гарантии предоставляют «мягкие» операционные системы реального времени

Я думаю, что знаю, что такое «жесткая» операционная система реального времени. Это операционная система с планировщиком, которая предоставляет контракт с программистом приложения. Приложение предоставляет крайний срок для каждого запроса на выделение ресурсов. Если запросы крайнего срока осуществимы , планировщик гарантирует, что каждый ресурс будет выделен запрашивающему приложению до крайнего срока. Эта гарантия достаточна для того, чтобы программист мог рассуждать о максимальных задержках и минимальной пропускной способности конкретных запросов.

Все определения «мягких» систем реального времени, которые я нахожу, кажутся мне пустыми. Википедия говорит

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

Uhhhh. Ладно. По этим критериям Windows 95 была мягкой системой реального времени, как и 3BSD, как и Linux. Википедия не является хорошим источником, но следующая пара хитов Google не намного лучше. Например, http://users.ece.cmu.edu/~koopman/des_s99/real_time/ говорит

В мягкой системе реального времени можно допустить ухудшение работы при редко возникающей пиковой нагрузке.

Это не контракт, это причудливый способ ничего не сказать.

Каковы примеры реальных мягких гарантий / контрактов в реальном времени, предлагаемых реальными операционными системами?

Я ищу ответы в форме:

В (OS-name), если программист делает (что нужно программисту), то операционная система гарантирует (что гарантирует система).

Вы правильно поняли, и Википедия настолько информативна, насколько это возможно - мягкое в реальном времени - это не формальная характеристика, это оценочное суждение. Другой способ сказать «мягкое в реальном времени» - «Хотелось бы, чтобы это было в реальном времени» или, точнее, «это должно быть в реальном времени, но это слишком сложно».

Если вы действительно хотите выразить свое мнение в форме гарантии, это гарантия наилучших усилий, а не гарантия конкретной производительности.

Или, чтобы процитировать Erlang FAQ (Erlang - это язык программирования, изначально разработанный для использования в телефонии):

Что означает мягкое в реальном времени?

Циники скажут "в принципе ничего".

(…) Многие телекоммуникационные системы предъявляют менее строгие требования [чем в режиме реального времени], например, им может потребоваться статистическая гарантия в духе «поиск базы данных занимает менее 20 мс в 97% случаев». Мягкие системы реального времени, такие как Erlang, дают вам такую ​​гарантию.

И это дает полезное определение. Мягкий режим реального времени указывает на дизайн, который оптимизирован для каждой отдельной задачи, занимающей не более определенного количества времени , а не для оптимизации общего времени, затрачиваемого на выполнение всех задач. Например, мягкая система реального времени будет стремиться завершить 99,9% запросов за 10 мс и обработать 100 запросов в секунду, тогда как не в реальном времени может стремиться выполнить 200 запросов в секунду, но позволить случайному запросу заблокировать для 50 мс или больше. Жесткий режим в реальном времени гарантирует один запрос каждые 15 мс, несмотря ни на что.

Мягкое реальное время используется для приложений, где пропущенный срок означает снижение качества обслуживания, но не критично для производительности. Мультимедиа и телефония являются типичными примерами использования. Каждый аудио или видеокадр должен быть обработан по времени, иначе он должен быть пропущен; но пропуск кадра не конец света. Проектировщики Erlang преследовали аналогичные цели в отношении надежности в других вопросах: они отметили, что для телефонной станции было бы лучше иногда прерывать вызов, но быть абсолютно уверенным, что обмен в целом продолжит работать, что бы ни случилось, чем когда-либо рискуют катастрофическим отказом в попытке поддержать связи любой ценой.

Напротив, что-то вроде управления двигателем требует, чтобы программное обеспечение никогда не пропускало крайний срок. Это сопряжено с затратами: общая производительность, как правило, ниже, и может быть достигнуто только относительно простое поведение. С другой стороны спектра приложение обработки чисел обычно заботится только об общей производительности - важно то, как быстро умножаются матрицы 1000x1000, а не как быстро вычисляется каждый столбец.

Linux с набором патчей -rt (в реальном времени) предоставляет планировщик, который обеспечивает интересную гарантию, которая кажется не пустой. (Хотя мне непонятно, как можно реально использовать гарантию.)

Политика SCHED_FIFOпланирования Linux-rt работает следующим образом: пользователь назначает приоритет каждому процессу. (Номера приоритетов для процессов в режиме реального времени - от 0 до 99, а традиционные niceзначения Unix от -20 до 19 соответствуют приоритетам от 100 до 139. (Таким образом, «0» - это «самый высокий» приоритет, а «139» - «самый низкий»). "приоритет.)

Гарантия заключается в том, что в любое время планировщик будет планировать Nвыполняемые задания с наивысшим приоритетом на Nпроцессорной машине. Были предприняты большие усилия, чтобы избежать проблем инверсии приоритетов внутри ядра. Когда процесс Aстановится работоспособным и имеет более высокий приоритет, чем какой-либо другой запущенный процесс B, он Aбудет немедленно выгружен B.

Тем не менее, обратите внимание, что нет строгих временных гарантий. Время, потраченное на выполнение вытеснения, теоретически может быть сколь угодно долгим. Кроме того, кажется, что есть некоторые способы, которыми задание с низким приоритетом может инициировать множество операций ввода-вывода с большой задержкой. Когда ввод / вывод завершается, обработчики прерываний для задания с низким приоритетом могут прервать работу с более высоким приоритетом, что, возможно, является формой инверсии приоритета.

Таким образом, предоставляется ограниченная гарантия: если существует один процесс с наивысшим приоритетом, то, когда он работает, он получает все ресурсы процессора, которые ОС может ему реально предоставить. Если у вас есть хороший верхний предел количества ресурсов процессора, потребляемых процессом с наивысшим приоритетом, вы можете рассчитать достаточно точную оценку ресурсов, которые будут доступны процессу с наивысшим приоритетом, и так далее.

Подробная статья, посвященная планировщику реального времени в Linux, находится по адресу http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler .

Чтобы определить «мягкое в реальном времени», проще всего сравнить его с «жестким в реальном времени».

Говоря небрежно, большинство людей неявно имеют неформальную ментальную модель, которая рассматривает информацию или событие как «в реальном времени»

• если или в той степени, в которой это проявляется для них с задержкой (задержкой), которая может быть связана с его предполагаемой валютой

• т. Е. В тот период времени, когда информация или событие имеют для них приемлемо удовлетворительное значение.

Существует множество различных специальных определений «жесткого реального времени», но в этой ментальной модели жесткое реальное время представлено термином «если». В частности, если предположить, что действия в реальном времени (например, задачи) имеют крайние сроки завершения, приемлемо удовлетворительное значение события, когда все задачи выполнены, ограничивается особым случаем, когда все задачи соответствуют их срокам.

Жесткие системы реального времени делают очень сильные предположения о том, что все в приложении, системе и среде является статичным и известно априори - например, какие задачи, периодичность, время прибытия, периоды, сроки, которые они выиграли не имеют конфликты ресурсов, и в целом время эволюции системы. В системе управления полетом самолета или в автомобильной тормозной системе, а также во многих других случаях эти предположения обычно могут быть соблюдены, так что все сроки будут соблюдены.

Эта ментальная модель преднамеренно и очень полезна достаточно обобщенно, чтобы охватить как жесткое, так и мягкое реальное время - мягкое приспособлено к фразе «до такой степени». Например, предположим, что событие завершения задачи имеет неоптимальное, но приемлемое значение, если

• не более 10% задач не укладываются в сроки
• или нет задачи более 20%
• или среднее опоздание по всем задачам не более 15%
• или максимальное опоздание среди всех задач составляет менее 10%

Все это типичные примеры мягких кейсов в реальном времени во многих приложениях.

Рассмотрим одно задание: забрать ребенка после школы. Это, вероятно, не имеет фактического срока, вместо этого есть некоторая ценность для вас и вашего ребенка, основанная на том, когда это событие имеет место. Слишком ранняя трата ресурсов (таких как ваше время) и слишком поздно имеют какую-то отрицательную ценность, потому что ваш ребенок может остаться один и потенциально в опасности (или, по крайней мере, получить неудобства)

В отличие от статического жесткого особого случая в реальном времени, мягкое реальное время делает только минимально необходимые специфические для приложения предположения о задачах и системе, и ожидаются неопределенности. Чтобы забрать своего ребенка, вам нужно ехать в школу, и время для этого будет динамичным в зависимости от погоды, условий движения и т. Д. У вас может возникнуть соблазн чрезмерного обеспечения вашей системы (т. Е. Позволить то, на что вы надеетесь, наихудшее время вождения), но опять же это напрасная трата ресурсов (ваше время и занятие семейного автомобиля, возможно, отказ в использовании другими членами семьи).

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

Очевидно, что боевые сценарии имеют множество возможных динамических неопределенностей, которые должны быть учтены управлением ресурсами. Мягкие системы реального времени также очень распространены во многих гражданских системах, таких как промышленная автоматизация, хотя очевидно, что военные являются наиболее опасными и неотложными для достижения приемлемой удовлетворительной ценности.

Краеугольным камнем систем реального времени является «предсказуемость». Трудный случай в реальном времени интересует только один особый случай предсказуемости - то есть, что все задачи будут соответствовать их срокам, и максимальное событие будет достигнуто этим событием. Этот особый случай называется «детерминированным».

Существует спектр предсказуемости; большинство систем реального времени (а именно, мягких) имеют недетерминированную предсказуемость, например, время завершения задач и, следовательно, значения, полученные из этих событий. В целом, предсказуемость и, следовательно, ценность могут быть сделаны настолько близкими к детерминированной конечной точке, насколько это необходимо, но по цене, которая может быть физически невозможной или чрезмерно дорогой (например, в бою или, возможно, даже в том, чтобы забрать вашего ребенка из школы).

Мягкое реальное время требует специфического для приложения выбора вероятностной модели (а не модели распространенных частот) и, следовательно, модели предсказуемости для рассуждений о задержках событий и результирующих значениях.

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

• вероятность того, что ни одна задача не пропустит свой срок более чем на 5%, больше 0,87.

В приложении противоракетной обороны, учитывая тот факт, что в бою преступник всегда имеет преимущество перед защитой, какой из этих двух сценариев вычислений в реальном времени вы бы предпочли:

• поскольку идеальное уничтожение всех вражеских ракет маловероятно или невозможно, назначьте свои защитные ресурсы, чтобы максимизировать вероятность того, что многие из наиболее угрожающих (например, в зависимости от их целей) вражеских ракет будут успешно перехвачены (близкий перехват учитывается, потому что это может сдвинуть вражескую ракету с курса);

• Жалуйтесь, что это не проблема вычислений в реальном времени, потому что она динамическая, а не статическая, и традиционные концепции и методы в реальном времени не применяются, поэтому вы не заинтересованы в проведении НИОКР для мягкого реального времени.

Несмотря на различные недопонимания относительно мягкого реального времени в компьютерном сообществе реального времени (но не в других областях, не связанных с вычислениями), мягкое реальное время является очень общим и мощным и потенциально очень сложным по сравнению с жестким в реальном времени.

Чтобы напрямую ответить на вопрос ОП:

• жесткая система реального времени может обеспечить детерминированные гарантии - чаще всего, что все задачи будут соответствовать их срокам, время ответа на прерывание или системный вызов всегда будет меньше, чем x, и т. д. - ЕСЛИ И ТОЛЬКО ЕСЛИ сделаны очень строгие предположения, и они верны, что все, что имеет значение, является статичным и известно априори (в общем, такие гарантии для жестких систем реального времени являются открытой проблемой исследования, за исключением довольно простых случаев)

• мягкая система реального времени не дает детерминированных гарантий, она предназначена для обеспечения максимально возможной аналитически заданной вероятностной своевременности и предсказуемости своевременности, которые возможны в текущих динамических условиях, в соответствии с критериями, специфичными для приложения. Очевидно, что жесткое в реальном времени является простым частным случаем мягкого реального времени. Очевидно, что мягкие аналитические недетерминированные заверения в реальном времени могут быть очень сложными для предоставления, но они обязательны в наиболее распространенных случаях в реальном времени (включая наиболее опасные критические для безопасности, такие как боевые действия), так как большинство случаев являются динамическими, а не статическими.

На моем сайте real-time.org я подробно и подробно обсуждаю темы реального времени, жесткого реального времени, мягкого реального времени, предсказуемости, детерминизма и смежные темы .