Какие аспекты ThreadX делают ее ОС реального времени?

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

Однако истинное определение заключается в том, что система должна гарантировать, что некоторые заданные операции всегда будут выполняться в течение известного детерминированного времени (т.е. времени в секундах, а не в относительном выражении). Ни Linux, ни Windows не работают в реальном времени. Компьютер с Linux или Windows может быть настолько быстрым, что все, что вы хотите сделать, почти всегда будет происходить достаточно быстро, но нет гарантии, что это всегда будет выполнено в течение максимального времени. Если вы создаете программную систему для управления медицинским устройством или огромным заводским оборудованием, вам нужно что-то остановить или запустить за x-миллисекунд, а не «вскоре» или «обычно достаточно быстро».

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

Что касается вашего конкретного вопроса, с веб-сайта ThreadX:

ThreadX is deteriminstic. A high priority thread starts responding to 
an external event on the order of the time it takes to perform a 
highly optimized ThreadX context switch.

    - Boot time: 300 cycles
    - Context switch time: <100 cycles
    - Semaphore get: 30 cycles

Все это означает, что ваше время отклика детерминировано. Это одна из самых важных вещей, которые вам нужны в RTOS.

В threadx ваши темы имеют приоритет. Операционная система управляется аппаратным таймером прерывания, а планировщик обеспечивает правильное планирование потоков в соответствии с их приоритетом.

Например, если поток A (высокий приоритет) ожидает на семафоре, а поток B (низкий приоритет) работает, то, как только семафор станет доступным, поток B будет прерван и запущен поток A.

Threadx имеет ряд других функций для оптимизации времени переключения контекста. Например, у каждого потока есть свой стек.

Для более подробной информации вы должны получить это: https://rads.stackoverflow.com/amzn/click/com/1578201349

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

В RTOS, если приходит поток с высоким приоритетом, то поток с низким приоритетом будет приостановлен до тех пор, пока поток с высоким приоритетом не завершится (или не перейдет в состояние ожидания/приостановки). Поток с низким приоритетом никогда не получит время (включен квант времени события), пока не будет активен любой поток с высоким приоритетом.

В случае одинакового приоритета потока, если включен временной интервал, каждый поток получит определенное количество времени.

Вы также должны проверить инверсию приоритета в случае RTOS.

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