Почему ОСРВ считаются детерминированными?

На ПК (конечно же, в ОС) любая C-программа становится неопределенной с точки зрения времени. Например, цикл занимает от 1,2 до 1,3 секунды в зависимости от того, «как быстро я перемещаю другое окно». Это потому, что ОС заставляет процессы (или потоки) распределять вычислительную мощность.

Что касается ОСРВ (во встроенной системе), то, когда мы пишем многопоточное приложение, я думаю, что то же самое происходит в зависимости от того, сколько потоков выполняется одновременно.

У меня нет инструментов, чтобы точно это проверить на встроенной системе. Таким образом, я хотел спросить. Является ли мое беспокойство разумным или я упускаю что-то очень фундаментальное?

РЕДАКТИРОВАТЬ : Я приведу пример. у нас есть задача 1 (занимает 10 мс) и задача 2 (занимает 20 мс). Они начали одновременно на двух отдельных потоках. Я утверждаю (также обеспокоен, не уверен), что задача 1 занимает более 10 мс, поскольку они разделяют вычислительную мощность с задачей 2.

Это неправда, что задачи в ОСРВ автоматически детерминированы, но можно наложить гораздо более жесткие ограничения на то, когда и как часто задачи запускаются. ОСРВ обычно обеспечивает жесткие приоритеты для задач; в любое время выполняется готовая задача с наивысшим приоритетом. Автор кода также имеет полный контроль над тем, какой набор задач выполняется; Вы можете разумно ожидать, что нет высокоприоритетных фоновых задач, которые могли бы прервать ваш код, скажем, для обмена данными на диск, если вы не записали их.

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

Что касается ОСРВ (во встроенной системе), то, когда мы пишем многопоточное приложение, я думаю, что то же самое происходит в зависимости от того, сколько потоков выполняется одновременно.

НЕТ!

Если это произойдет, то это не ОС реального времени (ОСРВ).

Краткий ответ заключается в том, что определение ОСРВ не имеет ничего общего с многозадачностью или приоритетом. Просто у всех задач есть временные гарантии .

Остальная часть того, что вы считаете характеристиками ОСРВ (расстановка приоритетов, выполнение задач и т. Д.), Является всего лишь следствием (или особенностями) построения системы, в которой задачи должны завершаться в течение заданного промежутка времени.

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

ОСРВ обычно не гарантирует пропускную способность , вместо этого она позволяет гарантировать задержку .

Обычно это достигается с помощью системы приоритетов, например, здесь, во FreeRTOS:

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

Предположим, у вас есть задача с приоритетом 1, для обработки события которой требуется 10 мс, задача с приоритетом 2, которая обрабатывает другое событие, за 100 мс, и фоновая задача с приоритетом 3. Если вы ожидаете получить одно событие приоритета 1 не чаще, чем каждую секунду, вы можете сказать, что наихудший случай обработки события приоритета 2 - 10 мс + 100 мс. Задача с приоритетом 3 может быть произвольно замедлена событиями, но вам все равно - потому что это низкий приоритет.

Я бы предпочел, чтобы это был комментарий, но он занимает слишком много символов. В любом случае, ozgur, судя по вопросам в ответах на ваши комментарии, вы, похоже, упускаете из виду тот факт, что вы не можете просто сказать, что мой поток работает так долго и ожидает, что он волшебным образом будет работать вместе с другими потоками, благодаря ОС. Вы должны спроектировать свои потоки и проанализировать их на худшую производительность. Если наихудший случай не соответствует вашим требованиям, то вам нужно изменить дизайн темы.

Таким образом, вместо того, чтобы просто сказать, что поток 1 завершается за 10 мс, а поток 2 - за 20 мс, вы также должны сказать, что поток 1 должен выполняться каждые 15 мс. поток 2 должен выполняться каждые 40 мс. поток 3 должен выполняться каждые 500 мс, поток N должен выполняться каждые 1500 мс. Затем вы выделяете время для завершения каждого потока в худшем случае. Вы собираете все это вместе, выявляете наихудшие возможные сценарии, а затем вы должны убедиться, что каждый поток соответствует требованиям времени. В этом анализе вы также указываете, должны ли некоторые потоки иметь более высокий приоритет, чем другие, чтобы соответствовать их требованиям к синхронизации.

Например, поток 5 выполняется прерывается потоком 4, который прерывается потоком 3, который прерывается потоком N, может быть одним из худших сценариев. Вы помещаете все это на временную шкалу и проверяете, что даже в этом наихудшем сценарии каждый поток соответствует требованиям к синхронизации. Вы можете гарантировать, что потоки завершат этот худший сценарий детерминистически, используя планировщик и приоритеты в ОС реального времени. Именно этот детерминизм делает ОС реального времени.

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

В таких ОС, как Windows, вы не только не можете указать, когда будет запущен каждый поток, вы даже не можете гарантировать, что ваше приложение будет работать в любой момент времени. ОС может остановить ваше приложение и запустить какой-либо фоновый сервис, когда захочет. Другими словами, нет детерминизма. Таким образом, Windows не является операционной системой реального времени. Хотя, если ваши требования к времени велики, например, (thread1 запускается каждые 10 секунд, thread2 запускается каждые 15 секунд), вы можете по существу относиться к Windows как к операционной системе реального времени, если учитывать учет спада и примерно каждые 10 или 15 секунд. (дайте или возьмите несколько сотен миллисекунд и случайное пропущенное окно) достаточно хорошо.

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

Наша система состоит из оружия, которое стреляет шарами с постоянной скоростью, двух ящиков, которые «ловят» шары и продвигаются на один шаг с каждым пойманным мячом. Оружие можно переключить на стрельбу из одного из ящиков, но оно теряет один шар при каждом переключении. Первому ящику понадобится 1000 шагов (шаров), чтобы добраться до конца, а ящику 2 понадобится 2000.

Сценарий 1 (задания один за другим):
- пистолет стреляет 1000 шаров в коробку 1, переключается (стоит 1 шар) и бросает 2000 шаров в коробку 2, в общей сложности 3001 шар .

Сценарий 2 (задачи «одновременные»):
- пистолет стреляет 5 шарами в одну коробку, переключается и стреляет 5 шарами в другую коробку, чтобы создать видимость одновременности . Стоимость переключения составляет (1000/5 x 2 =) 400 шаров. Таким образом, после выстрела 2400 шаров коробка 1 достигнет своего конца, а коробке 2 понадобится еще 1000 шаров, чтобы достичь ее конца, в общей сложности 3400 шаров .

Применив эти результаты к вашему сценарию, Задача 1 и первая половина Задачи 2 завершатся через 24 мс, а вторая половина Задачи 2 завершится за дополнительные 10 мс, что в общей сложности составит 34 мс. Это ясно показывает , что время , необходимые для выполнения задач увеличиваются из - за потерянное время в переключении между задачами . Эти результаты также эквивалентны Задаче 1, занимающей 12 мс, и Задаче 2, требующей 22 мс.