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"?
Hi ich kenne zwar Keil RTX nicht aber alles andere als den Scheduler aufzurufen wenn ein Task blockiert wäre, naja, suboptimal. Matthias
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.
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.
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).
Bei einem kooperativen Realtime System wird der Scheduler bei jedem Taskwechsel aufgerufen. Also bei jedem waitSema() und dergleichen.