Paralelle Schleife mit mehreren Aufgaben

Hallo Leute und freues neues Jahr,

ich programmiere meistens mit mehreren paralellen Loops, die zwischeneinander mittels Synchronisationstools (Queue, Notifier...) kommunizieren. Leider bleibe ich immer wieder an einem Problemchen stehen. Und zwar, wenn so eine paralelle Schleife mehrere Aufgaben hat, z.B.:

Daten von Schnittstelle immer lesen
nur einzelne Pakete lesen
im binären Modus
im ASCII Modus
Fehlerbericht senden
Schnittstellenstatus senden
Schleife beenden

und und und

Dann weiss ich nicht so genau wie ich aus dem Ständiglesenmodus rauskomme um andere Aufgaben zu erledigen. Zur Zeit frage ich in jedem Schleifendurchlauf den Status der Schleifenqueue ab (ob neue Elemente/Befehle in der Verbraucherqueue anstehen) und wenn ja komme aus dem Modus raus. Früher habe ich in jedem Schleifendurchlauf in die eigene Queue den Befehl "Lesen" geschoben.

Wie macht ihr das?
Gibt es Alternativen dazu?

Anzeige

' schrieb:Zur Zeit frage ich in jedem Schleifendurchlauf den Status der Schleifenqueue ab (ob neue Elemente/Befehle in der Verbraucherqueue anstehen) und wenn ja komme aus dem Modus raus.

So mach ich das auch.

Nach jedem Lesen in dem Dauerlesecase wird die Queue gecheckt. Je nach Befehl in der Queue wird das Dauerlesen beendet oder nur ein spezieller Befehl ausgeführt und danach wieder das Dauerlesen (respektive der zuletzt gültige Case) ausgeführt.

' schrieb:So mach ich das auch.

Nach jedem Lesen in dem Dauerlesecase wird die Queue gecheckt. Je nach Befehl in der Queue wird das Dauerlesen beendet oder nur ein spezieller Befehl ausgeführt und danach wieder das Dauerlesen (respektive der zuletzt gültige Case) ausgeführt.

Dann bin ich schon mal nicht alleine.
Sonst noch Vorschläge?

' schrieb:Dann bin ich schon mal nicht alleine.
Sonst noch Vorschläge?

ich verwende die Information "Queue timed out" und schicke meine StateMachine dann in den "timeout" Case. Diesen Case kann man wunderbar verwenden die Statemachine in weitere States zu schicken. Beispiel:

3 Cases:
timeout, lesen und schreiben

Die StM soll alle 100 lesen ==> Queue Read timeout = 100 ms

im Read Case merke ich mir den Zeitstempel des letzten Lese-Vorganges
im Write Case überprüfe ich, ob seit dem letzten Lesen bereits mehr als 100 ms vergangen sind, wenn ja füge ich einen Read Case ein (damit bei voller Q das Lesen nicht zu kurz kommt ...)

wenn keine Elemente in der Queue sind springt die StM in den "timeout" case und schchickt sich darin selbst in den "Read" Case ==> die State-Machine springt alle 100 ms in den Read Case ...

' schrieb:ich verwende die Information "Queue timed out" und schicke meine StateMachine dann in den "timeout" Case. Diesen Case kann man wunderbar verwenden die Statemachine in weitere States zu schicken. Beispiel:

3 Cases:
timeout, lesen und schreiben

Die StM soll alle 100 lesen ==> Queue Read timeout = 100 ms

im Read Case merke ich mir den Zeitstempel des letzten Lese-Vorganges
im Write Case überprüfe ich, ob seit dem letzten Lesen bereits mehr als 100 ms vergangen sind, wenn ja füge ich einen Read Case ein (damit bei voller Q das Lesen nicht zu kurz kommt ...)

wenn keine Elemente in der Queue sind springt die StM in den "timeout" case und schchickt sich darin selbst in den "Read" Case ==> die State-Machine springt alle 100 ms in den Read Case ...

Als Vorschlag angenommen, aber effizient finde ich das nicht. Kannst du die Vorteile dieser Vorgehensweise aufzählen? Ich weiss, dass du nichts umsonst machst, also was sind denn die Vorteile davon?

Ich persönlich versuche keine Timeouts im Programm zu verwenden, die mag ich nicht so. Bei mir ist fast alles eventgesteuert.

OFFTOP: Trennst du das Schreiben und Lesen in zwei Loops oder machst du es immer in einer "Schnittstellenloop"?

' schrieb:Als Vorschlag angenommen, aber effizient finde ich das nicht. Kannst du die Vorteile dieser Vorgehensweise aufzählen? Ich weiss, dass du nichts umsonst machst, also was sind denn die Vorteile davon?

Ich persönlich versuche keine Timeouts im Programm zu verwenden, die mag ich nicht so. Bei mir ist fast alles eventgesteuert.

den Timeout-Case brauchst du sowieso, da du die "Dequeue Element" Primitive ja mit einem Timeout versehen musst. -1 ginge auch, aber dann wartet die Primitive ggf. ewig, oder man muss die Queue zerstören um die Schleife beenden zu können. (Error 1122 occurred at Dequeue Element in Untitled 1 | Possible reason(s): LabVIEW: Refnum became invalid while node waited for it.) Das mach ich aber nicht so gerne, weil für mich auch ein "geregeltes Herunterfahren" zu einem "sauberen" Programm gehört ...

' schrieb:OFFTOP: Trennst du das Schreiben und Lesen in zwei Loops oder machst du es immer in einer "Schnittstellenloop"?

Radio Eriwan: im Prinzip ja, aber: kommt drauf an, welche Funktionalität ich benötige ...

Anzeige

' schrieb:den Timeout-Case brauchst du sowieso, da du die "Dequeue Element" Primitive ja mit einem Timeout versehen musst. -1 ginge auch, aber dann wartet die Primitive ggf. ewig, oder man muss die Queue zerstören um die Schleife beenden zu können. (Error 1122 occurred at Dequeue Element in Untitled 1 | Possible reason(s): LabVIEW: Refnum became invalid while node waited for it.) Das mach ich aber nicht so gerne, weil für mich auch ein "geregeltes Herunterfahren" zu einem "sauberen" Programm gehört ...
Radio Eriwan: im Prinzip ja, aber: kommt drauf an, welche Funktionalität ich benötige ...

:Dwoher kennst du das Radio???


Ja, aber du kannst doch ein Exit kommandieren, dann brauchst du die Queue nicht zu zerstören um aus der Schleife rauszugehen.

Ungefähr so: