Как отличить ОСРВ от Linux? - PullRequest
Новая
       35

Как отличить ОСРВ от Linux?

1 голос
/ 27 марта 2019

У меня работают ОСРВ QNX и Ubuntu 17.10. Проблема в том, что кроме того, что QNX является ОСРВ, у меня нет никаких доказательств того, что она ведет себя как система RT. Какое приложение я должен запускать в каждой ОС, что может дать мне четкое различие между ответом RT RTOS и Ubuntu?

Я запустил программу-обработчик сигналов (обработчик прерываний) на обоих, чтобы увидеть, какой из них первым перехватит прерывание. 

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <pthread.h>

void sig_hand(int sig) {
    printf("signal received\n");
    exit(0);
}

void *sigfun(void *arg) {
    signal(SIGINT, sig_hand);
    while(printf("Thread running\n"));
    return NULL;
}


int main(void) {
    pthread_t th;

    pthread_create(&th,NULL,sigfun,NULL);
    pthread_join(th,NULL);

    return 0;
}

Я ожидаю, что пока поток продолжает печатать Thread Running, QNX извлечет прерывание и остановит поток быстрее по сравнению с Ubuntu. Тем не менее, я не вижу разницы, и, вероятно, это не то приложение, чтобы выяснить более быстрый отклик RT. Может кто-нибудь предложить мне лучший способ провести четкое различие между ОСРВ и Ubuntu?

Ответы [ 2 ]

1 голос
/ 28 марта 2019

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

Операционная система общего назначения (GPOS), такая как Linux, обычно использует планировщик совместного использования времени с равным приоритетом с циклическим перебором, что обеспечивает справедливое распределение времени среди ряда процессов.Таким образом, чем более обработан процесс и чем он занят (используя больше доступного временного интервала), тем менее отзывчивым он становится.

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

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

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

0 голосов
/ 27 марта 2019

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

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

Для случайного примера представьте, что вы делали ту же самую операцию (например, выделяли несколько страниц ОЗУ) 50 миллионов раз;и обнаружил, что на одной ОС время наихудшего случая составляло 5000 наносекунд (но это всегда занимало 5000 наносекунд, поэтому среднее время нахождения также составляет 5000 наносекунд);и обнаружил, что в других ОС время наихудшего случая составляет 7000 наносекунд, но оно почти всегда занимает 100 наносекунд (а среднее время нахождения составляет 123 наносекунды).Сравнивая наихудшее время (5000 против 70000), вы знаете, что первая ОС - лучшая ОС реального времени.Сравнивая среднее время наблюдения (5000 против 123), вы знаете, что вторая ОС является лучшей ОС «не в реальном времени».

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

...