Wann wird bei einem RTOS der Scheduler aufgerufen?

[M. G. (looking)]

Wann wird bei einem RTOS, außer aus dem regelmäßigen Timerinterrupt für 
den Scheduler, der Scheduler sonst noch aufgerufen?

Als Beispiel soll Keil RTX für Cortex dienen, Pre-emptive Scheduling, 
Schedulertick soll 10 ms sein.

Fall 1:
Ein Interrupt wird ausgelöst, dadurch soll dann per Event ein Task 
angetriggert werden.
Laut http://www.keil.com/support/man/docs/rlarm/rlarm_ar_clock_task.htm
wird nach Ende der ISR der Scheduler durch Antriggern des 
Timerinterrupts direkt aufgerufen.

Fall 2:
Ein laufender Task ist an einem Punkt angelangt, an dem er auf ein Event 
wartet. Er geht dann in den Zustand wartend und gibt die Kontrolle an 
andere Tasks ab. Wird nun der Scheduler direkt aufgerufen oder erst 
wieder, wenn der Schedulertick kommt?
Das könnte dann ja im worst-case hier 10 ms dauern, wird dann in dieser 
Zeit die Rechenzeit "verbraten"?

[Μαtthias W. (matthias)]

Hi

ich kenne zwar Keil RTX nicht aber alles andere als den Scheduler 
aufzurufen wenn ein Task blockiert wäre, naja, suboptimal.

Matthias

[(prx) A. K. (prx)]

M. G. schrieb:

> Fall 1:
...
> wird nach Ende der ISR der Scheduler durch Antriggern des
> Timerinterrupts direkt aufgerufen.

Ja.

> Fall 2:
...
> andere Tasks ab. Wird nun der Scheduler direkt aufgerufen

Ja.

[900ss (900ss)]

Was ich so an RTOS kennengelernt habe, wird dem Scheduler bei jedem 
Timertick und bei fast allen Kernel-API-Aufrufen die Gelegenheit gegeben 
die Task zu wechseln sofern eine höher priorisierte Task bereit ist.
Ob das bei Keil auch so ist, weis ich nicht, aber wie schon geschrieben, 
alles andere wäre dumm.

Sicher ist das aber ein Frage für den Support von Keil.

[(prx) A. K. (prx)]

Es gibt bei einem preemptive RTOS nicht selten zwei Sorten Interrupts. 
In das RTOS eingebettete und davon unabhängige.

Die unabhängigen rufen keine RTOS-Funktionen auf und kehren genau 
dorthin zurück, wo sie hergekommen sind.

Die eingebetteten können in eine andere Task zurückkehren als diejenige, 
die sie unterbrochen haben. Dabei ist es nicht relevant, ob dieser 
Interrupt vom RTOS-Timer stammt oder von irgendeiner Schnittstelle.

Bei eingebetteten Interrupts wie auch bei Kernel-Aufrufen gibt es oft 
ein Flag, das vor der Rückkehr zum Programm signalisiert, dass sich in 
der Task-Verwaltung etwas geändert hat und es sich lohnt, mal wieder 
nachzusehen, wohin die Reise gehen sollte. Wobei dieses Flag sogar in 
Hardware implementiert sein kann (Cortex-M).

[Purzel H. (hacky)]

Bei einem kooperativen Realtime System wird der Scheduler bei jedem 
Taskwechsel aufgerufen. Also bei jedem waitSema() und dergleichen.