Definition: Preemptive oder non-preemptive

http://de.wikipedia.org/wiki/Multitasking#Pr.C3.A4emptives_Multitasking
http://en.wikipedia.org/wiki/Preemption_(computing)
http://en.wikipedia.org/wiki/Nonpreemptive_multitasking
http://www.uni-protokolle.de/Lexikon/Pr%E4emptives_Multitasking.html

MaWins Erklärung ist völlig korrekt, wobei man gern den Begriff 
"cooperative multitasking" statt "non-preemptive" verwendet. Schon weil 
sich daraus direkt das zugrunde liegende Verfahren ergibt: Die Task 
kooperiert explizit mit dem BS. Ob Prioritäten im Spiel sind oder nicht 
ist unerheblich - wobei ich allerdings bisher noch keinen RT-Kernel 
erblickt habe, in dem das nicht vorgesehen wäre.

Schmeiss mal einen Link zu den merkwürdigen Aussagen von Keil rein.

Verwirrter schrieb:

> Die Tasks können vom BS unterbrochen werden,
> obwohl sie noch nicht fertig sind, was laut "unserer" Definition
> bedeutet es sei preemptive.

So stimmts aber dann doch nicht, denn auch in kooperativem Multitasking 
können Tasts vor Beendigung unterbrochen werden. Aber eben nur an 
Stellen, wo sie das explizit vorsehen.

So gibt es bei solchen Kernels typischerweise eigens einen Kernelaufruf, 
der nichts anderes tut, als dem Kernel zu signaliseren, dass jetzt ggf. 
eine andere Task ran darf und die laufende Task wieder in die 
Warteschlange gestellt werden kann.

Programme für kooperativem Multitasking können daher recht oft mitten in 
der Verarbeitung etliche solcher Aufrufe enthalten, um die Wartezeit 
anderer kritischerer Tasks gering zu halten. Denn die Reaktionszeit 
kritischer Tasks ist eben diese Zeit zwischen solchen Aufrufen (wozu 
auch viele andere Kernelaufrufe gehören können).

Es liegt aber in der Natur der Sache, dass preemptives Multitasking 
stets mit mit Prioritäten einhergeht, während einfachere kooperative 
Kernels auch ohne Prioritäten Sinn ergeben können.

Helfer schrieb:

> Laut Specs-Übersicht
> http://www.phaedsys.org/principals/keil/keil-RTOS/keilrtx166.html ist
> der preemptive Context Switch beim RTXtiny 166 nicht implementiert.

Diese Übersicht macht klar, dass RTX166-Tiny ein einfaches kooperatives 
Multitasking ohne Prioritäten implementiert. D.h. die Task werden 
vermutlich zyklisch reihum aktiviert und reihen sich an entsprechenden 
Programmstellen freiwillig wieder hinten ein.

> Wie geht es nach der Unterbrechung durch das BS weiter? Kann ein Context
> Switch erfolgen oder wird immer zu dem unterbrochenen Task
> zurückgekehrt?

Die "Unterbrechung" sieht beispielsweise so aus:

1

while (1) {

2

   ... Arbeit für zig bis hunderte Mikrosekunden ...

3

   RtxYield();

4

}

Der (von mir erfundene) Kernelaufruf RtxYield erlaubt es dem Kernel, an 
dieser Stelle auf eine anderes Task umzuschalten. Die laufende Task 
landet dann am Ende der Wartschlange und kommt irgendwann später wieder 
dran.

Verwirrter schrieb:
> @prx
> http://www.keil.com/rtx166tiny/
> dritter Punkt : Preemptive task switching and task priorities are not
> supported


> Die Tasks können vom BS unterbrochen werden,
> obwohl sie noch nicht fertig sind


Das deckt sich aber nicht mit dem was ich dort lese.

Da steht explizit, dass nur cooperatives Multitasking unterstützt wird. 
Was ja soviel heißt wie: Das Betriebssystem unterbricht von sich aus 
keinen Task, sondern der Task muss explizit an das Betriebssystem 
zurückgeben und so einen Taskwechsel erlauben.

Aufpassen: Ein Task muss ja nicht 'fertig' sein, wenn er an das BS 
zurückgibt. Er kann ja auch einfach nur 'fair' sein und zb den 
Wagenrücklauf eines Druckers dazu benutzen, während des Ausdruckens 
einem anderen Task eine Chance zu geben. Der Task erlaubt daher, dass er 
unterbrochen wird, obwohl er noch nicht fertig ist. Das ist aber etwas 
anderes als wie wenn er gnadenlos vom BS nach Ablauf seiner Zeitscheibe 
interrupted wird.

Verwirrter schrieb:

> Doch, der Task wird vom Betriebssystem unterbrochen, ohne dass er seine
> Rechenzeit freiwillig abgibt.
> *Getestet mit Keil µVision 3*

Das steht nun aber für RTX 166-Tiny eindeutig im Widerspruch zu Keils 
Doku. Würde es entgegen eindeutiger Dokumentation Tasks an beliebiger 
Stelle durch andere Tasks (nicht Interrupts!) unterbrechten, dann wäre 
es unbenutzbar.

Was genau ist "Toggle"?

Ok, damit ist klar, dass der non-preemptive Kernel von Keil tatsächlich 
preemptive ist. Denn was hier passiert und in der Doku auch aufgeführt 
wird ist eben eine preemption, eine Unterbrechung der Task an von der 
Task nicht kontrollierbarer Stelle.

Für mich wäre ein solcher Kernel ziemlich problematisch, weil man 
deshalb wie in einem preemptive Kernel programmierung muss, ohne aber 
über die dafür nötigen Synchronisationsmechanismen wie Semaphoren und 
Mutexe zu verfügen. Dieser Kernel kombiniert die Nachteile eines 
cooperative Kernels mit den Nachteilen eines preemptive Kernels.

In einem echten non-preemptive Kernel kann sich darauf verlassen, dass 
zwischen zwei Kernel-Aufrufen mit Sicherheit nicht auf eine andere 
Task umgeschaltet wird. Weshalb man gemeinsam benutzte Daten innerhalb 
solcher Codesequenzen nicht durch Mutexe absichern muss und gemeinsam 
benutzte Funktionen nicht reentrant sein müssen, was die Programmierung 
erheblich vereinfacht und weit weniger fehlerträchtig ist.

Beim Keil Kernel muss man das hingegen genau das tun, hat aber keine 
Mutexe zur Verfügung und kann sich daher nur über Abschaltung von 
Interrupts oder Zeitkalkulation (keine 5ms seit dem letzten Aufruf von 
os_wait) absichern. Das Risiko ist, dass man sich über kurz oder lang 
einen extrem schwer nachvollziehbaren Fehler durch Taskunterbrechung an 
ungünstiger Stelle einhandelt.

Als Beispiel für diese Problematik:

1

void Toggle(int pon)

2

{

3

   // bewusst als 3 getrennte Operationen formuliert:

4

   int temp = port; // (1)

5

   temp ^= 1<<pin;  // (2)

6

   port = temp;     // (3)

7

}

8

9

void toggle_p1(void) task 0

10

{

11

 while(1)

12

 {

13

  Toggle(p1);

14

 }

15

}

16

17

void toggle_p2(void) task 1

18

{

19

 while(1)

20

 {

21

  Toggle(p2);

22

 }

23

}

Hier kann es nun passieren, dass Task 0 zwischen (1) und (3) 
unterbrochen wird und Task 1 zum Zuge kommt. Erstens muss Toggle nun 
reentant sein. Zweitens wird Task 0, wenn sie später wieder dran kommt, 
den alten vor vielen Millisekunden nach temp geladenen Wert in den Port 
schreiben und damit u.U. eine Änderung des zur anderen Task gehörenden 
Pins rückgängig machen.

Dieser Code müsste also modifiziert werden, damit er unter allen 
Bedingungen funktioniert:

1

void Toggle(int pon)

2

{

3

   disable_interrupts();

4

   // bewusst als 3 getrennte Operationen formuliert:

5

   int temp = port; // (1)

6

   temp ^= 1<<pin;  // (2)

7

   port = temp;     // (3)

8

   enable_interrupts();

9

}

A. K. schrieb:
> In einem echten non-preemptive Kernel kann sich darauf verlassen, dass
> zwischen zwei Kernel-Aufrufen mit Sicherheit nicht auf eine andere
> Task umgeschaltet wird.

Round Robin im RTX166 Tiny kann abgeschaltet werden (Round-Robin Timeout 
im Konfigurationsfile auf 0 setzen), dann dürfte nicht mehr an nicht 
kontrollierbarer Stelle auf eine andere Task umgeschaltet werden.