Каква е правилната дефиниция на латентността на прекъсване в RTOS?

Прочетох две различни дефиниции за „закъснение при прекъсване“ в RTOS.

  1. „В компютрите латентността на прекъсването е времето, което изтича от момента на генериране на прекъсване до момента, в който източникът на прекъсването е обслужен“ (източник: https://en.wikipedia.org/wiki/Interrupt_latency )

  2. „Способността да се гарантира максимална латентност между външно прекъсване и началото на манипулатора на прекъсване.“ (източник: Какво прави едно ядро/ОС в реално време? )

Сега въпросът ми е каква е правилната дефиниция на „закъснение при прекъсване“?

Например:

Времево клеймо за възникване на външно прекъсване: 00 ч:00 мин.:20 секунди
Времево клеймо, когато изпълнението е прескочено вътре в ISR: 00 ч:00 мин.:25 секунди< br> Времеви печат, когато изпълнението излиза от ISR след обслужване: 00 ч:00 мин.:43 секунди

Какво е времето за забавяне на прекъсването? 5 секунди ли са? или 23 секунди?


latency interrupt rtos
person sniper    schedule 08.10.2015    source източник
comment
Второто е дефиниция на детерминизъм, а не латентност.   -  person Clifford    schedule 20.10.2015

Отговори (1)


arrow_upward
1
arrow_downward

Мисля, че първото определение е правилно, но не сте разбрали как прекъсванията работят на практика и какво означава "обслужван".

Контролният поток е триетапно HW прекъсване -> прекъсване на услугата -> процес. ISR обикновено е много кратък и просто изчиства източника на прекъсването и маркира процеса като готов за изпълнение.

Пример е, че имате процес, който извиква read за достъп до данни на диска. Този процес ще блокира, докато дискът не изпълни IO. След като се появи IO, HW предизвиква прекъсване, за да уведоми процесора, който влиза в ISR, изчиства прекъсването и след това настройва процеса, който е бил блокиран, като способен да бъде планиран.

Защо това е латентността на прекъсването, която трябва да се измери? Защото тук действително необходимата обработка върши работата. И ако прекъсването се нуждае от отговор в определено време (т.е. това е система в реално време), тогава трябва да знаем времето от прекъсването до момента, в който започнем да обработваме този отговор. Което означава, че трябва да знаем латентността от прекъсването до момента, в който нашият процес в реално време бъде планиран.

person dave    schedule 08.10.2015
comment
Да, прав си, грешно съм разбрал термина "сервизиран". От вашия отговор, ако разбирам правилно, мога ли да кажа, че латентността на прекъсването е времето, необходимо на ядрото за изчистване на прекъсването и деблокиране на блокираната (при това прекъсване) нишка? - person sniper; 08.10.2015
comment
@Benvin : Бих казал, че не. Забавянето на прекъсването е само времето между събитието на прекъсване и началото на манипулатора на прекъсване. Времето, необходимо за превключване на контекст към задача, е време за превключване на контекст и се определя от вашата RTOS реализация, а времето, необходимо за изпълнение на манипулатора на прекъсване, е във ваш контрол (т.е. вие пишете кода - той е толкова бързо и детерминистично, колкото го направите). Времето, необходимо от прекъсването до изпълнението на нишката на манипулатора, може да е важно и трябва да бъде детерминистично, но това не е закъснение при прекъсване. - person Clifford; 20.10.2015