Реално-времева операционна система

Реално-времева операционна система (на английски: Real-time operating system, съкратено RTOS) е операционна система, създадена с цел да обслужва приложения в реално време, които обработват данните, докато идват, обикновено без буферно забавяне. Изискванията за време на обработка (включително всякакво забавяне от страна на операционната система) се измерват в десетини от секундата или в по-малки интервали. Реално-времевата система е система, обвързана с времето, която има ясно определени времеви ограничения. Обработването на данните трябва да бъде извършвано в рамките на определените ограничения или системата ще се провали. Системите, които се водят от събития, превключват между задачи, в зависимост от приоритета им, докато системите със споделено време превключват задачите, в зависимост от прекъсванията на клока.

Ключова характеристика на RTOS е нивото на последователност спрямо времето, което е нужно за приемането и завършването на задача от дадено приложение. Променливостта се нарича джитер. Тежката реално-времева операционна система има по-малко джитер, отколкото леката реално-времева операционна система. Основната проектна цел не е висока скорост на пренос на данни, а по-скоро гаранция за лека или тежка категория на производителност. RTOS, която обикновено или по принцип се справя с даден срок е лека, но ако може детерминистично да спазва сроковете, то тя е тежка RTOS.

RTOS има сложен алгоритъм на диспечера. Гъвкавостта на диспечера позволява по-широки приоритети на процесите, но реално-времевата операционна система най-често се използва за тесен кръг от приложения. Сред ключовите фактори за една RTOS са минималното време за отговор на прекъсванията и минималното време за превключване на нишките. Една такава операционна система се цени повече за това колко бързо и колко предсказуемо може да отговори, отколкото за това колко работа може да извърши за даден период от време.

Диспечер

Обикновено задачата има три състояния:

Повечето задачи са блокирани или в готовност през повечето време, тъй като обикновено само една задача може да бъде изпълнявана в даден момент на процесор. Броят обекти на опашката за готовност може да варира в широки граници, в зависимост от броя на задачите и вида на диспечера.

Най-често структурата на данните в списъка за готовност в диспечера е проектирана така, че да свежда до минимум най-голямата продължителност на времето, изразходвано в критичната част на диспечера, когато присвояването е възпряно, а понякога дори всички прекъсвания са изключени. Изборът на структурата на данните зависи от максималният брой задачи, които могат да изчакват в списъка за готовност.

Ако никога няма повече от няколко задачи в списъка за готовност, тогава двойно свързан списък за готовност често е оптимален. Ако списъкът обикновено съдържа няколко задачи, но понякога съдържа и повече, то тогава списъкът следва да се подрежда по приоритет. Вмъкването на задача изисква преминаването по списъка, докато се достигне края му или се намери задача с по-нисък приоритет.

В по-напредналите системи реално-времевите задачи споделят изчислителни ресурси с много задачи, които не са в реално време, а списъкът за готовност може да е с произволна дължина.

Беше ли полезна тази статия?

Оцени я!

Среден рейтинг / 5. Брой гласове:

Ако намираш статията за полезна...

Последвай ни в социалните мрежи!

Съжаляваме, че тази статия не ти беше полезна!

Помогни ни да променим това!