Kooperatives Multitasking und Interrupt?

Ja, der Thread ist alt. Aber so kann ich das nicht stehen lassen.

In einem reinen kooperativen Multitasking Betriebssystem für 
Mikrocontroller wird ein Task auf keinen Fall von einem Interrupt 
unterbrochebn.
In einem solchen System ist nur ein einziger Interrupt aktiv und das ist 
ein beliebiger Timer-Interrupt, der für die Tick-Erzeugung zuständig 
ist.
Alles andere wird gepollt und auf keinen Fall mit Interrupts gehandhabt.

Nö. Gegenbeispiel: TinyOS.

Ja, aber...?
Der Timer-Interrupt unterbricht die Tasks nicht?
Und ein anderer Interrupt (z.B. UART) würde sich wie genau von einem 
Timer-Interrupt unterscheiden?
Und vor allem: warum, wer verbietet andere Interrupts?

Weil die Vorhersagbarkeit des Systems darunter leidet.

gnd3 schrieb:
> Ja, aber...?
> Der Timer-Interrupt unterbricht die Tasks nicht?
> Und ein anderer Interrupt (z.B. UART) würde sich wie genau von einem
> Timer-Interrupt unterscheiden?
> Und vor allem: warum, wer verbietet andere Interrupts?

Es wird ein fester Intervall mit dem Timer erzeugt, z.B. 10 ms.
Jeder Task muss dann kürzer als diese 10 ms + OS-Overhead sein.

Dann unterbricht sich nämlich überhaupt nichts.

Rufus Τ. Firefly schrieb:
> Kooperatives Multitasking impliziert aber keine maximalen Taskdauern.

Eben, das ist ja das Problem daran - ein nicht kooperierender Task kann 
das System zum Stillstand bringen. So ist echtes Real Time unmöglich.

Logisch ist: Interrupts stören das kooperative Multitasking überhaupt 
nicht, sie begrenzen nur die Real Time Fähigkeit. Da kMT-Systeme aber 
sowieso nicht realtimefähig sind, spielt das keine Rolle, 
hardwareorientierte Interrupts wie Bedienung von Schnittstellen sind 
ohne weiteres möglich, und in Bezug auf die Laufzeit müssen sie auch 
nicht besser sein als die Zeitscheiben der Tasks.

Gruss Reinhard

PS im Gegenteil, ein gut designtes Interruptsystem kann dafür sorgen, 
dass Wartezeiten in den Tasks nicht auftreten und das System viel 
flüssiger läuft - ohne wirklich Real Time zu werden.

Falk Brunner schrieb:
> Dann ist dein Task buggy.

Natürlich, aber im echten Leben kommt das halt vor. Du hast den 
Unterschied zwischen kooperativ und präemptiv offensichtlich nicht 
verstanden, vor allem nicht wozu das gut sein soll. Aber das kann hier 
in diesem Task nicht geklärt werden, das ist ein Thema für sich.

Gruss Reinhard

Falk Brunner schrieb:
>>Natürlich, aber im echten Leben kommt das halt vor.
>
> Sicher, genauso wie dein präemtiver Scheduler buggy sein kann.

Das ist es eben, was du nicht verstehst: eine Task ist NICHT Bestandteil 
des Betriebssystems, das BS soll aber weiterlaufen auch bei einer 
fehlerhaften Task. Wer unter 16bit-Windows kooperativ entwickelt hat und 
bei jeder unbeabsichtigten Endlosschleife den Rechner neu booten musste, 
weiss was das wert ist.

Ich glaube auch nicht, dass ich mit dieser Meinung allein stehe, 
auffallenderweise gibt es praktisch kein BS mit kooperativem MT mehr. 
Oder sind alle Windows-, Linux-, Solaris usw. Entwickler bloss zu blöd?

Der wesentliche Punkt bei Real Time ist übrigens nicht die Zeit, trotz 
der Namensgebung, sondern die Garantie dafür, und da gibt es nichts zu 
dehnen. Ein kooperatives System kann garnichts garantieren.

Gruss Reinhard

Reinhard Kern schrieb:
> Rufus Τ. Firefly schrieb:
>> Kooperatives Multitasking impliziert aber keine maximalen Taskdauern.
>
> Eben, das ist ja das Problem daran - ein nicht kooperierender Task kann
> das System zum Stillstand bringen.

Beim präemptiven Multitasking mit Realtime gilt das auch, sofern es 
keine anderen Tasks mit gleicher oder höherer Priorität gibt. Mit 
hochprioren Tasks, die sich in irgendeine Schleife verrennen, kannst du 
auch jedes präemptive Realtime-System zum Sterben bringen. Das geht ja 
auch gar nicht anders. Wenn hochpriore Tasks einfach so durhc 
niederpriore unterbrochen werden können (was bei 
Desktop-Betriebssysstemen auch der Fall ist), ist tatsächlich kein 
Realtime möglich.

> So ist echtes Real Time unmöglich.

Daß ein fehlerhaftes Programm nicht so funktioniert, wie gewünscht, 
verwundert nicht besonders. Daraus kann man aber nicht schließen, daß 
dann gar keins so funktioniert, wie gewünscht.

Reinhard Kern schrieb:
> Falk Brunner schrieb:
>>>Natürlich, aber im echten Leben kommt das halt vor.
>>
>> Sicher, genauso wie dein präemtiver Scheduler buggy sein kann.
>
> Das ist es eben, was du nicht verstehst: eine Task ist NICHT Bestandteil
> des Betriebssystems, das BS soll aber weiterlaufen auch bei einer
> fehlerhaften Task.

Was ist denn "das Betriebssystem"? Auch nix anderes als Tasks, und noch 
ein paar ISRs.

> Wer unter 16bit-Windows kooperativ entwickelt hat und
> bei jeder unbeabsichtigten Endlosschleife den Rechner neu booten musste,
> weiss was das wert ist.

Und wer unter Linux+Xenomai (also einem präemptiven System) 
Realtime-Software entwickelt, weiß den Xenomai-Watchdog zu schätzen, der 
hängende Tasks nach einer wählbaren Anzahl von Sekunden abschießt, eben 
auch, damit man nicht immer das System neu booten muß. Denn alle 
Betriebssystem-Tasks, bis hin zur Auslagerung, sind natürlich 
niederpriorer als alle Realtime-Tasks.

> Der wesentliche Punkt bei Real Time ist übrigens nicht die Zeit, trotz
> der Namensgebung, sondern die Garantie dafür, und da gibt es nichts zu
> dehnen. Ein kooperatives System kann garnichts garantieren.

Das System alleine kann sowieso nichts garantieren, und Programme kann 
man immer so schreiben, daß sie die Echtzeit-Anforderungen nicht 
erfüllen. Das hat aber nichts damit zu tun, ob der Scheduler kooperativ 
oder präemptiv ist.

Also ein Echtzeitsystem nur mittels koopMT zu machen halte ich (wie 
erwähnt) für äusserst kritisch, denn nur ein Übeltäter-Task kann (wie 
erwähnt) schnell alles lahm legen.
Wenn man kein complett preemt.MT machen will, kann man aber doch 
kooperative (typ.weise nicht zeitkritische) Tasks mit niedriger INT-Prio 
laufen lasssen,
und zeitkritischere 'Tasks' über ISRs abhandeln. Je höher die 
Zeitanforderung, desto höher die INT-Prio.

MCUA schrieb:
> und zeitkritischere 'Tasks' über ISRs abhandeln. Je höher die
> Zeitanforderung, desto höher die INT-Prio.

kann man die INT-Prio eigentlich verändern? Die Rangfolge der 
Auslösungen ist ja statisch festgelegt und die Sprungadressen auch, also 
nicht änderbar?

MCUA schrieb:
> Also ein Echtzeitsystem nur mittels koopMT zu machen halte ich (wie
> erwähnt) für äusserst kritisch, denn nur ein Übeltäter-Task kann (wie
> erwähnt) schnell alles lahm legen.

Allerdings löst sich (wie erwähnt) dieses Problem bei präemptivem 
Multitasking nicht einfach in Luft auf.

> Wenn man kein complett preemt.MT machen will, kann man aber doch
> kooperative (typ.weise nicht zeitkritische) Tasks mit niedriger INT-Prio
> laufen lasssen,
> und zeitkritischere 'Tasks' über ISRs abhandeln. Je höher die
> Zeitanforderung, desto höher die INT-Prio.

Das finde ich unsauber. ISRs und Tasks sollten sauber getrennt bleiben, 
und ISRs sollten so kurz wie möglich sein. D.h. wenn irgendwo Daten 
ankommen, die zur Auslösung eines Interrupts führen, wird in der ISR 
z.B. über eine Semaphore ein Task "ent-blockiert", der dann die 
angekommenen Daten verarbeitet. Über die Prioritäten der Tasks kann man 
dann einstellen, in welcher Reihenfolge diese Verabeitung erfolgt, wenn 
mehrere Interrupts quasi gleichzeitig ausgelöst werden. Das geht dann 
auch bei Prozessoren, die keine einstellbaren Interrupt-Prioritäten 
haben.

Peter Binder schrieb:
> MCUA schrieb:
>> und zeitkritischere 'Tasks' über ISRs abhandeln. Je höher die
>> Zeitanforderung, desto höher die INT-Prio.
>
> kann man die INT-Prio eigentlich verändern?

Das hängt vom Prozessor bzw. Interrupt-Controller ab.

> Die Rangfolge der Auslösungen ist ja statisch festgelegt und die
> Sprungadressen auch, also nicht änderbar?

Sagt wer?

Aber bei kMT bestimmt die Task wann umgeschaltet wird und weiss deshalb 
was sie retten muss. Uch mach ab znd zu mal Echtzeit und finde da 
eigentlich kMT besser zu händeln. Das funktioniert aber nur solange wie 
jedes Stück Software das läuft von mir ist bzw. einsehbar ist.

>Bei den üblichen Systemen ist weiterhin
pro Task ein Stack erforderlich, da der Taskswitch zwar nicht an jeder
Stelle im Programm stattfinden kann, aber an so ziemlich jeder Stelle im
Stack.

versteh ich den 2. Teil nicht

heinz schrieb:
> Aber bei kMT bestimmt die Task wann umgeschaltet wird und weiss deshalb
> was sie retten muss.

Die Umschaltung erfolgt in der Regel in irgendwelchen API-Funktionen des 
Systems. Die wissen aber nichts davon, was der Aufrufer noch so alles 
auf dem Stack liegen hat.

> Uch mach ab znd zu mal Echtzeit und finde da eigentlich kMT besser zu
> händeln. Das funktioniert aber nur solange wie jedes Stück Software das
> läuft von mir ist bzw. einsehbar ist.

Dann mag das gehen, aber eine saubere Trennung von Programm und 
Scheduler kann ich mir so nicht recht vorstellen.

okay - ich hab den stack als Speicher verstanden.

>bei bestimmten System-calls (z.B. blockierendes
deshalb sag ich ja
>jedes Stück Software das läuft

1. kann ich sowas vermeiden (zumindest versuchen)
2. wenn der handler von mir ist, ist der auch kooperativ

Anderes beispiel malloc - die gibts in Echtzeit nicht. Alles statisch

Oder wie schon oben geschrieben - SPS.
Die ist zumindest weiche Echtzeit und kann relativ hart programmiert 
werden.

>Das finde ich unsauber. ISRs und Tasks sollten sauber getrennt bleiben,
>und ISRs sollten so kurz wie möglich sein. D.h. wenn irgendwo Daten
>ankommen, die zur Auslösung eines Interrupts führen, wird in der ISR
>z.B. über eine Semaphore ein Task "ent-blockiert", der dann die
>angekommenen Daten verarbeitet. Über die Prioritäten der Tasks kann man
>dann einstellen, in welcher Reihenfolge diese Verabeitung erfolgt, wenn
>mehrere Interrupts quasi gleichzeitig ausgelöst werden. Das geht dann
>auch bei Prozessoren, die keine einstellbaren Interrupt-Prioritäten
>haben.
- Ein Interrupt-Controller (sofern vorhanden) ist gerade dazu da, 
niedriger prio INTs von der Hardware fern zuhalten. Aus diesem Grund 
macht es gerade keinen Sinn bei eintreffen eines INTs nur den passenden 
Task anzuwerfen und sofort die aktuelle INT-Prio zurück zu setzen.

- Je 'sauberer' man es programmiert desto mehr Overhead ist auch 
vorhanden. Wenn schon eine Task nur bei Eintreffen eines bestimmten INTs 
aufgerufen werden soll, und man diese Task direkt von dem INT ausführen 
lässt, kann man sich die explizite Zuweisung der Task-Priorität an den 
Task eigentlich ersparen, weil der INT sowiso schon die betreffende Prio 
hat.

>Oder wie schon oben geschrieben - SPS.
Die ist norm total simpel, weil nur eine Zeitscheibe erforderlich. Für 
typ. SPS-Programme bräuchte man nichtmal INT-Funktion, geschweige denn 
verschiedene INT-Prioritäten.

Reinhard Kern schrieb:
> Der wesentliche Punkt bei Real Time ist übrigens nicht die Zeit, trotz
>
> der Namensgebung, sondern die Garantie dafür, und da gibt es nichts zu
>
> dehnen. Ein kooperatives System kann garnichts garantieren.

Falsch.

Gegenbeispiel: Wir verwenden für ein Flight Control System (großes 
Flugzeug, Zulassung) kooperatives non-preemtive multitasking. Abgesehen 
davon wird bis auf einen Timer-Interrupt kein weiterer verwendet.
Die formalen Nachweise, die für eine Zertifizierung erbracht werden 
müssen sind bei der Verwendung von Interrupts schwer bis unmöglich 
nachzuweisen.

nochmal SPS
Nehmen wir mal an ich programmier in der keine Sprünge und keine Alarm 
Bausteine ( = Interupt) Dann ist deren Laufzeit komplett voraussagbar. 
Das ist ein BS in dem nur eine Task läuft.

nochmal preempetiv gegen kooperativ
Wenn die Task die Kontrolle freiwillig abgibt dann kann sie vorher ihren 
Zustand selbst retten und entlastet den Scheduler (sofern vorhanden.

ich hab das schon so realisiert
6 Tasks - jede hat genau ein Doppelwort DD TASKn
wenn Task1 beendet ist rettet sie ihren Zustand und springt zu Task2

push ..
push..
mov ebx,[offs1]
mov TASK1,ebx

mov ebx,TASK2
jmp ebx
offs1:

ich denk mal das ist der "Scheduler" mit den geringst möglichen Kosten

und die Laufzeit ist zumindest halbwegs berechenbar (worst case)
ist beim 80x86 eh nicht richtig machbar weil zB. cache miss usw.

im Gegensatz dazu muß beim Taskwechsel über einen Timer alles gerettet 
werden
das ist beim 80x86 ne Menge

>
> im Gegensatz dazu muß beim Taskwechsel über einen Timer alles gerettet
> werden
> das ist beim 80x86 ne Menge

Naja 8 Register + 3-5 die automatisch gepusht werden sind im vergleich 
zu anderen Architekturen geradezu lächerlich.

DO-178C schrieb:
> Gegenbeispiel: Wir verwenden für ein Flight Control System (großes
> Flugzeug, Zulassung) kooperatives non-preemtive multitasking.

Also ihr schreibt die ganze Software - davon rede ich nicht, sondern 
davon, dass BS aus einer und die Apps aus anderen Händen kommen, und 
dann sollte das BS möglichst nicht von fehlerhaften Apps in 
Mitleidenschaft gezogen werden.

Schön wenn ihr so erfolgreich zusammenarbeitet, aber das ist nicht immer 
der Fall, nicht einmal in derselben Firma muss das so sein. Und generell 
schadet Fehlertoleranz ja nicht, ausser dem nötigen Aufwand.

Gruss Reinhard

>Also ihr schreibt die ganze Software - davon rede ich nicht, sondern
davon, dass BS aus einer und die Apps aus anderen Händen kommen, und
dann sollte das BS möglichst nicht von fehlerhaften Apps in
Mitleidenschaft gezogen werden.

Unbekannte Apps... ja. Dann ist das kooperative MT schon weg.
kMT bedeutet zwingend alles aus einem Guss.

Schwierig wird es mit dynamischem Speicher. Denn der besteht nur einmal, 
und ist daher eine Resource, deren Zugriff gelock werden muss. Das kann 
man umgehen, indem man jedem Task einen eigenen Heap aus dem grosszuegig 
bemessenen Speicher fest zuweisen kann.

>Naja 8 Register + 3-5
+ float
+ ein paar flags +++

>Schwierig wird es mit dynamischem Speicher.
Daher wenn iw machbar statisch.

@Reinhard Kern
wie erhöhst Du die Fehlertoleranz bei einem Echtzeitsystem ?

heinz schrieb:
> wie erhöhst Du die Fehlertoleranz bei einem Echtzeitsystem ?

wieso erhöhen, verglichen womit? das BS darf einer Task natürlich nur 
eine maximale Zeitscheibe erlauben - so "echtzeitig" ist eben dann das 
System. Das ist doch wohl fester Bestandteil jedes ernstzunehmenden 
RTOS, und im übrigen ja die Definition von Präemptiv. Die Task kann ja 
ruhig in einer Endlosschleife laufen, sie wird halt nach der 
garantierten maximalen Latenzzeit abgebrochen und darf ihre 
Endlosschleife irgendwann später fortsetzen. Dieses Zeitverhalten gehört 
ja zu den wesentlichen technischen Daten, die der RTOS-Hersteller 
garantieren muss.

Ist ja eigentlich sehr einfach: kann das BS eine Task, die sich nicht 
freiwillig selbst unterbricht, nicht mit Gewalt beenden (ist das BS also 
nicht präemptiv), so kann vom BS auch keine maximale Reaktionszeit 
garantiert werden - es ist also nicht echtzeitfähig.

Man kann ja, wenn man die gesamte Software erstellt, schon ein 
bestimmtes Zeitverhalten erreichen (oder wenigstens dran glauben), aber 
dadurch wird das Betriebssystem ja kein Echtzeit-BS.

Gruss Reinhard

ich hab das auf deine Aussage
>Und generell schadet Fehlertoleranz ja nicht, ausser dem nötigen Aufwand.
bezogen.

Das was Du beschreibst ist ein BS für ein Desktop

Ein RTOS hat ganz andere Anforderung. Nicht nur das Einhalten von 
Deadtime
Und ja wenn ich die Software komplett schreibe kann ich immer ein 
Zeitverhalten errechnen. Wenn ich nur zyklische Tasks hab ist das 
relativ einfach. Bei azyklischen hab ich dann eben einen worst case. Ob 
man das aber ein BS nennen kann???

Mir gings eigentlich um den overhead den RTOS bei der Taskumschaltung 
bringt.

Naja, bei einem wirklich rein kooperativenMultitaskingBetriebssystem 
(bei dem sonst wirklich nichts zugelassen ist) kann in der Tat ein 
falscher Task das Ding lahm legen. Das muss aber nicht zwingend heissen, 
dass dort auch ein fehlerhafter Task vorhanden ist. Je nach BS ist die 
Wahrscheinlichkeit mehr oder weniger gross. (Bei Win98 war es extrem, 
aber das interessiert nat in der uC Welt keinen). (Aber auch jedes 
andere BS kann Fehler haben -wo auch immer- weshalb es dann doch hängen 
bleibt.


>Man kann ja, wenn man die gesamte Software erstellt, schon ein
>bestimmtes Zeitverhalten erreichen (oder wenigstens dran glauben), aber
>dadurch wird das Betriebssystem ja kein Echtzeit-BS.
Doch. Echtzeit ist es dann, wenn der Schreiber (oder Entwickler) der das 
Gerät rausbringt garantieren kann, dass die Zeitbedingungen erfüllt 
werden, völlig wurscht wie die BS-Architektur ist (Selbst wenn überhaupt 
kein uC drin sitzt). (So wie der Barkeeper inner Disco garantieren muss, 
spätestens nach 2 Minuten das Bier zu bringen, egal nach welchem 
Algorithmus)

MCUA schrieb:
> Doch. Echtzeit ist es dann

Echtzeit ja, Echtzeit-BS nein. Bitte Begriffe auseinanderhalten.

Reinhard Kern schrieb:
> Echtzeit ja, Echtzeit-BS nein. Bitte Begriffe auseinanderhalten.

Bevor man sie auseinanderhalten kann, sollte man sie erst definieren, 
dann diskutiert es sich viel leichter!

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

DO-178C schrieb:
> Falsch.
>
> Gegenbeispiel: Wir verwenden für ein Flight Control System (großes
> Flugzeug, Zulassung) kooperatives non-preemtive multitasking. Abgesehen
> davon wird bis auf einen Timer-Interrupt kein weiterer verwendet.
> Die formalen Nachweise, die für eine Zertifizierung erbracht werden
> müssen sind bei der Verwendung von Interrupts schwer bis unmöglich
> nachzuweisen.

;)

Was ich meinte war ein "einfaches" kooperatives Multitasking System für 
8 Bit Controller.
Natürlich muss man seine Tasks dann auch entsprechend gestalten.

>Echtzeit ja, Echtzeit-BS nein. Bitte Begriffe auseinanderhalten.
Wenn es ein System ist (egal welcher BS-Architektur) (und ohne System 
wird wohl nix laufen) und Echtzeit-Bedingungen garantiert werden können, 
muss man es wohl automatisch Echtzeit-BS nennen, sonst wird es 
Haarspalterei.

Bernhard M. schrieb:
> EGS_TI schrieb:
>> Was ich meinte war ein "einfaches" kooperatives Multitasking System für
>> 8 Bit Controller.
>> Natürlich muss man seine Tasks dann auch entsprechend gestalten.
>
> Trotzdem ist das, was Du beschrieben hast, eine Sonderform, nämlich ein
> "Time Triggered" System.
> "Kooperatives Multitasking" Sagt nichts darüber aus, wie und welche
> nterrupts verwendet werden, es definiert nur, daß eine Task "kooperativ"
> Rechenzeit abgeben muß und nicht zwangsweise beendet wird.

Ja natürlich. Aber das ist doch eine der sichersten Formen, wenn nicht 
sogar die sicherste.
Ich gehe davon aus, dass die Luftfahrtindustrie nicht umsonst eine 
solche Architektur verwendet.

DO-178C schrieb:
> Gegenbeispiel: Wir verwenden für ein Flight Control System (großes
> Flugzeug, Zulassung) kooperatives non-preemtive multitasking. Abgesehen
> davon wird bis auf einen Timer-Interrupt kein weiterer verwendet.

Wie behandelt Ihr dann UART & Co?
Per DMA oder habt Ihr so etwas gar nicht?