Ich wusste, ich hatte vergessen jemanden zu Antworten. :-)
> Wenn ich Dich richtig verstanden habe, bedeutet das run thread x
> nichts anderes, als das der thread x die Priorität 32 bekommt auch wenn er die schon hatte.
Richtig.
> In meinem Bsp. würde das bedeuten, der thread circilation_pump würde
> bei der wait-Bedingung stehen, wenn er durch die Schleife erneut aufgerufen würde
> und (wenn die wait-Bedingung noch immer zutrifft) sofort wieder verlassen.
Auch richtig.
> Ist vielleicht falsch ausgedrückt, er wird gar nicht aufgerufen wie eine Funktion, sondern
> er bekommt eine (ggf. neue) Priorität. Das war wohl mein falsches Verständnis von threads,
> sie können(sollten) nicht wie Funktionen behandelt werden, da sie einmal gestartet,
> in einer Endlsoschleife weiterlaufen.
Korrekt.
Threads können aber durch das Schlüsselwort reset; zurückgesetzt werden.
(Prio wie zum Programmstart, ggf. Capture lösen)
> Wenn ich das jetzt nicht falsch verstanden habe,
> dann kann ich meine threads, die ich in meinen loop´s der verschiedenen main-threads
> aufrufe, alle vor die loop-Schleife setzen, das sie ja eh in einer Endlosschleife laufen.
Richtig. Threads müssen nur einmal gestartet werden.(nicht aufgerufen!)
Um einen Vergleich mit Windows zu machen:
Man kann dies mit dem Aufruf eines odere mehrerer Programme vergleichen.
Nur, wenn diese beendet wurden (hier mit reset). müssen diese neu gestartet werden.
Natürlich gibt es noch halt. Hiermit "friert" man einen Thread ein.(vgl. run 0;)
Wird der Thread wieder gestartet, macht dieser an der Stelle weiter, wo er angehalten wurde.
Mit resume wird einem Thread die Prio vor der letzten Ã?nderung mit run oder halt zugewiesen.
> Ist für einen Insider sicherlich sonnenklar, aber wenn man aus anderen Programmiersprachen kommt,
> dann übersieht man halt leicht das Offensichtliche.(Asche über mein Haupt).
Multithreading ist eben etwas gewöhnungsbedürftig. :-)
> Auf mein Bsp. übertragen: das erneute Aufrufen bewirkt gar nichts, au�er dem Aufwand dem thread
> circulation_pump erneut die Priorität 32 zuzuweisen.
Korrekt.
> Aber das ist doch sicherlich eine ganze Menge weniger, als die Funktion
> circulation_pump zu durchlaufen ??????
Theoretisch ja, praktisch nein.
Das Threadhandling, das im hintergrund im OS abläuft, benötigt einiges an Rechenzeit.
Das hei�t, je mehr Threads es gibt, desto mehr Rechenzeit wird für das Threadhandling
benötigt, desto langsamer wird die CC2.
Darum: Nur so viele Threads wie nötig !
Darum lieber mehr mit if-Abragen arbeiten und diese kurz halten.(Einzeiler)
> Mir gefällt das mit den threads, weil ich -anders wie bei der CC1- nicht den ganzen Programmflu�
> stoppe, wenn eine wait-Bedingung nicht erfüllt ist. Viele Dinge mit wait zu lösen ist einfacher, als ein
> "Pumpen" von Komponenten durch viele Variablen zu verhindern oder permanent Ã?berwachungsfunktionen
> aufzurufen.
> Bsp.: Untere Temp-Grenze erreicht-> Kessel einschalten
>Â Â Â Â Â wait bis obere Grenze erreicht ist
>Â Â Â Â Â obere Temp-Grenze erreicht-> Kessel ausschalten
> das ging halt mit der CC1 nicht so.
> Nachdem ich das nun (hoffentlich) alles richtig verstanden habe, werde ich wohl in meinem Programm
> etliche Funktionen durch threads ersetzen(es gibt eine Menge Schleifen, wo gewartet werden muss, dass
> nach Stunden oder Tagen eine Ã?nderung eintritt).
Arbeite lieber weiter überwiegend mit Funktionen, sonst wird die CC2 irgendwan sehr langsam.
Eigene Threads nur dort, wo es sinnvoll ist.
Für die gesamte Regelung selbst benutze ich z.B. nur 3 Threads.
Ich habe nur den Mischer-Kreisen je einen eigenen Thread gegönnt.
Aber die Hauptregelung läuft in einem eigenem Thread ab.
Dazu habe ich noch einen Thread der die COM an hwcom übernimmt,
einen weiteren für mein Touch-Bedieneinheit an swcom für das gesamte
Menü, die Eingaben und System-Anzeigen.
Dann noch einen Thread für mehrere Terminals(Display+Tastatur) im Haus am I²C-Bus.
Ein geplanter Thread für I2CCOM, um die Regelung über I²C-Bus an meinen
lokalen Server zu binden.
Dann noch die im Hintergrund laufenden Threads für den AD-Multiplexer
und den Uhrenbaustein des CC2-ReglerBoards.
Somit komme ich schon auf 9 Threads.
Wenn Du jetzt jede Funktion in einen Thread packts, kommst Du schnell an die
Grenze von 254 Threads.
MfG André H.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: Thread / function (von ChristianK - 30.05.2003 16:28)