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

8

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

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

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

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

Ozgur
источник
Детерминизм включает в себя набор (и время) входов
PlasmaHH
3
Вам не хватает определения RTOS. ;-)
DrFriedParts
1
ОСРВ не используется для запуска отдельных задач, которые должны отвечать индивидуальным требованиям времени, она используется для запуска системы, которая в целом должна соответствовать всем требованиям времени. Детерминизм не означает «независимость от всех обстоятельств», это означает, что «когда я достаточно хорошо знаю обстоятельства (что определенно включает в себя задачи с более высоким приоритетом), я могу предсказать верхнюю границу».
Wouter van Ooijen

Ответы:

6

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

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

Ник Джонсон
источник
10

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

НЕТ!

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

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

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

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

DrFriedParts
источник
Таким образом, если задача 1 занимает 10 мс, а задача 2 - 20 мс отдельно. Если они запускаются одновременно (как два отдельных потока), они все равно будут завершены через 10 мс и 20 мс соответственно?
Озгур
2
В самом деле, весь смысл ОСРВ заключается в том, чтобы обеспечить выполнение задач с низким приоритетом одновременно с задачами с высоким приоритетом.
pjc50
1
@ pjc50 - я думаю, что ваш комментарий является критической точкой, которая, возможно, теряется. Вопрос содержит фундаментальное недоразумение. Нет «задачи 1 запущенной и задачи 2 запущенной одновременно »; задача с более высоким приоритетом (T1) будет останавливать / переопределять задачу с более низким приоритетом (T2) до тех пор, пока не закончится T1, или она не будет переопределена задачей с еще более высоким приоритетом (T0). Ясно, что ни одна ОС не может волшебным образом разрешать задачи, которым требуется больше, чем доступные ресурсы для выполнения их ограничений по времени, пространству и т. Д.
gbulmer
2
«Ни одна ОС не может волшебным образом разрешить задачи, которые требуют больше, чем доступные ресурсы» - действительно, это не может. Но настоящая ОСРВ позволит вам заранее определить, будет ли гарантировано, что все ваши ограничения будут выполнены.
JimmyB
1
@ozgur: вы неправильно понимаете приложения, работающие на ОСРВ. Вместо двух задач, которые занимают 10 мс и 20 мс, обычно приложения в ОСРВ имеют задачи, каждая из которых занимает 0,01 мс, но задача 1 должна выполнять КАЖДЫЕ 10 мс, а задача 2 должна выполняться КАЖДЫЕ 20 мс. Обычно в приложениях реального времени мы никогда не позволяем потокам работать параллельно, чтобы распределять мощность процессора. Вместо этого мы запускаем поток в течение максимально короткого времени, затем оставляем его спать. Смысл ОСРВ в том, что есть гарантии, что когда я попрошу его разбудить меня через 10 мс, он сделает это вместо 10,01 мс
slebetman
6

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

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

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

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

pjc50
источник
В вашем примере выполняются одновременно задача с приоритетом 1 и задача с приоритетом 2 (два потока запущены одновременно)?
Озгур
1
Потенциально да, или приоритет 1 запускается, когда приоритет 2 работает. В этом примере предполагается один процессор. Обратите внимание, что примерная спецификация также ограничивает количество задач P1, которые могут выполняться - если вы получаете событие P1 каждые 10 мс, а обработка занимает 10 мс, больше ничего не будет выполняться .
pjc50
Хорошо, вот мой вопрос. задача 1 (10 мс) началась одновременно с задачей 2 (100 мс). Я полагаю, что задача 1 занимает более 10 мс, потому что они разделяют вычислительную мощность с задачей 2. Я надеюсь, что прояснилась.
Озгур
Я думаю, что суть в том, что планировщик не будет запускать задачи 1 и 2 одновременно. Сначала он запустит задачу 1 (с более высоким приоритетом), а задачу очереди 2. Через 10 мс, когда задача 1 завершится, он запустит задачу 2.
michaelyoyo
1
Да, это не будет чередовать выполнение task1 и task2. Если задача P1 работоспособна, никакие задачи P2 не будут запланированы до ее завершения. Если задача P2 уже запущена, она будет прервана и приостановлена ​​до завершения всей работы P1.
pjc50
4

Я бы предпочел, чтобы это был комментарий, но он занимает слишком много символов. В любом случае, 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 секунд. (дайте или возьмите несколько сотен миллисекунд и случайное пропущенное окно) достаточно хорошо.

Замочить
источник
1

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

Наша система состоит из оружия, которое стреляет шарами с постоянной скоростью, двух ящиков, которые «ловят» шары и продвигаются на один шаг с каждым пойманным мячом. Оружие можно переключить на стрельбу из одного из ящиков, но оно теряет один шар при каждом переключении. Первому ящику понадобится 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 мс.

Guill
источник
Upvoted. Это объяснение сделало мой вопрос понятнее, а ответ очевиден.
Озгур