+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Queue und (kein) Dataflow (/Thread-Queue-und-kein-Dataflow)
Queue und (kein) Dataflow - NoWay - 29.05.2015 08:19
Hallo zusammen.
Als ich mit Labview einstieg, habe ich relativ schnell mit Queues gearbeitet. Das Dataflow Prinzip war zum damaligen Zeitpunkt nicht ganz so gefestigt, wie es heute der Fall ist. Man lernt ja schließlich jeden Tag etwas Neues. Nun habe ich es mir zur Aufgabe gemacht, ältere Anwendungen aus meiner Anfangszeit zu überarbeiten und gemachte Fehler auszumerzen und den Code im allgemeinen auf meinen "heutigen Wissenstand" zu optimieren.
Dabei ist mir eine sehr unschöne Sache aufgefallen, die mit den Queues zusammenhängt. Bei einer etwas größeren Anwendungen werden mehrere VI´s als Klon-UI´s aufgerufen, über die der Anwender diverse Steuerungsmöglichkeiten an die Hand bekommt. Dazu wurden verschiedene Queues verwendet, um z.B. Statusmeldungen an ein weiteres VI zu senden. Was die Queues machen, spielt erstmal keine Rolle, sondern wie ich sie implementiert habe. An dieser Stelle breche ich mit dem Datenflussprinzip indem ich in VI 1 ein Obtain mit dem Queuenamen ausführe, der Queue ihre Daten mitgebe und die Queuereferenz nicht explizit an das zweite VI weiterreiche. Die Queue erfasse ich dann im zweiten VI einfach durch den Aufruf eines weiteren Obtain Queue Elements mit dem gleichen Namen. Das führt natürlich dazu, dass man irgendwann total den Überblick verliert. Um dem entgegenzuwirken, will ich die Referenzen nun komplett durchverdrahten. Die Arbeit betrachte ich als Lehrgeld.
Was mich aber jetzt interessiert, ist die Tatsache was das neben der Unübersichtlichkeit für Konsequenzen haben kann. Könnt ihr mir dazu etwas sagen? Gewollt ist das sicher nicht, so wie ich es anfangs gelöst habe.
Gruß
NoWay
RE: Queue und (kein) Dataflow - jg - 29.05.2015 09:23
Queues brechen prinzipiell den Datenfluss, somit spricht erst einmal nichts gegen dein Vorgehen. Du musst bloß aufpassen, dass du pro "Obtain Queue" auch jeweils 1x "Release Queue" verwendest, ansonsten frisst das Speicher.
Ich persönlich verteile Queue-Refnums auch gerne per "Globaler Variable" oder per FGV.
Gruß, Jens
RE: Queue und (kein) Dataflow - Lucki - 29.05.2015 09:50
Schau Dir mal diese FGV an. Die FGV initialisiert sich beim ersten Aufruf. Damit braucht man keinen Schreibzugriff auf das FGV, es hat als einzigen Anschluß nur den Referenz-Ausgang. Man beachte auch rechts oben das sehr kleine Ikon, es ist kleiner als die meisten globalen Variablen. Damit kommt Ordnung in das System - zumindest was das Aussehen des BD betrifft.
RE: Queue und (kein) Dataflow - NoWay - 29.05.2015 10:21
Das heißt, ich erzeuge mir FGV´s mit den entsprechenden Datentypen für die Queues und brauche dann keine Queuenamen. Die Zuordnung erfolgt quasi über den VI Namen. Im Klartext: Drei unterschiedliche Queues, drei unterschiedliche FGVs mit den zugehörigen Datentypen. Anstelle der Obtain Queue Elemente rücken dann die FGV´s?
RE: Queue und (kein) Dataflow - jg - 29.05.2015 10:33
Ja, das ist eine Möglichkeit. Alternativ kannst du auch mehrere Queue-Refnums in einem FGV erzeugen und verwalten. Das liegt bei dir.
Gruß, Jens
RE: Queue und (kein) Dataflow - NoWay - 29.05.2015 10:40
Das ist ja richtig sexy
Spiele gerade damit rum und schon erschließen sich haufenweise neue Möglichkeiten. Danke für diesen Codeschnippsel!
RE: Queue und (kein) Dataflow - Kiesch - 29.05.2015 11:56
So wie ich verstanden habe, ist die FGV eigentlich nur für eine einzelne Queue brauchbar, die man an verschiedenen Stellen benutzt. Hier geht es so wie ich das verstanden habe ja eher um viele Queues die verwendet werden / werden sollen und darum, dass die bisher per Queue Name erzeugt werden (so dass über den Namen die Verknüpfung der beteiligten VIs entsteht).
Der offensichtliche Worst Case ist dabei natürlich, dass man Queues verbindet die eigentlich nix miteinander zu tun haben sollten, weil man die Übersicht verloren hat (= nicht so schön für die Wartbarkeit; wird nicht automatisch sichergestellt, dass das nicht der Fall ist).
Das muss aber nicht so gravierend sein, dass man deswegen alles ändern muss. Kann man ja auch durch Regeln zur Namensfindung sicherstellen.
*edit*
Da es auch zur Sprache kam: Klar kann man auch unterschiedliche Queues damit verwalten, aber letztendlich landet man dann doch wieder im Namensgebungsproblem. Und ob LV von Haus aus verwaltet, welche Namen man den Queues gegeben hat und die entsprechend verknüpft, oder ob das meine FGV für mich macht, ist dann unterm Strich vermutlich der gleiche Aufwand und hat das gleiche Problem (das man eindeutige Namen braucht an einer Stelle).
Dafür würde ich mir vermutlich nicht den Aufwand machen das umzubauen ^^
RE: Queue und (kein) Dataflow - Trinitatis - 29.05.2015 12:03
Der Vorteil bei der Verwendung der FGV liegt halt darin, dass es diese nur einmal gibt. Und darin kann ich ja auch mehrere Queuereferenzen verwalten.
Die Verwechslungssicherheit stelle ich über die Nutzung immer derselben FGV mit eindeutiger Namensgebung der Queue-Referenzenausgänge (wenn es denn mehrere sind)
Im übrigen muss ja auch der Datentyp passen - ich kann also nicht 2 verkehrte Queue-Referenzen miteinander verknoten, wenn deren DTyp nicht gleich ist.
Gruß, Marko
RE: Queue und (kein) Dataflow - BNT - 29.05.2015 15:29
(29.05.2015 09:23 )jg schrieb: Queues brechen prinzipiell den Datenfluss,...
Gruß, Jens
Das stimmt nicht. Queues brechen den Datenfluß NICHT! Ein Element wird in den Enqueuer hineingeschoben und kommt beim Dequeuer wieder heraus. Das ist Datenfluß, nur dass man den Draht nicht sieht. Die Daten bewegen sich sozusagen durch den Hyperraum.
Gruß Holger
RE: Queue und (kein) Dataflow - Kiesch - 01.06.2015 11:56
(29.05.2015 12:03 )Trinitatis schrieb: Der Vorteil bei der Verwendung der FGV liegt halt darin, dass es diese nur einmal gibt. Und darin kann ich ja auch mehrere Queuereferenzen verwalten.
Die Verwechslungssicherheit stelle ich über die Nutzung immer derselben FGV mit eindeutiger Namensgebung der Queue-Referenzenausgänge (wenn es denn mehrere sind)
Im übrigen muss ja auch der Datentyp passen - ich kann also nicht 2 verkehrte Queue-Referenzen miteinander verknoten, wenn deren DTyp nicht gleich ist.
Gruß, Marko
Bei der Frage ging es doch scheinbar um Skalierbarkeit auf sehr viele Queues mit unterschiedlichsten Namen. Wenn ich die in ner FGV mit ka 3 Ausgängen für die 3 Queues die ich möchte verwalten kann, dann kann ich auch gleich eindeutige Namen für die Zuordnung verwenden und mir darüber die Queues holen. Hab ich aber 100 Queues und bin mir deswegen nicht sicher ob es nicht doch mal bei der 101. zu ner Namenskollision kommt, dann ist meiner Meinung nach der FGV Ansatz genausogut / schlecht wie eindeutige Regeln zur Namensgebung. Schließlich kommt man bei so vielen Queues letztlich nicht umhin irgendwie anzugeben, welche genau man grade anfragen will. Und dann is man wieder dabei, dass man aus der FGV über nen Namen ne Queue Referenz holt - das kann LV numal auch schon mit Bordmitteln ohne FGV. Alternativ könnte man sicherlich auch nen Cluster bauen in den man alle Queue Referenzen reinpackt, dann dürfte sich LV vermutlich zumindest regen, wenn man eine Neue Queue identisch bezeichnen möchte. Allerdings wird auch das bei vielen Queues sicher schnell unübersichtlich.
Deswegen meiner Meinung nach: Wenn man durch sinnvolle Namensgebungsregelungen (Was weis ich; [Funktionsbeschreibung]_[VIName]_[Projekt]_[Out|In]) oder whatever sicherstellt, dass es eigentlich nicht zu Kollisionen kommen kann, dann fährt man genauso gut / schlecht wie mit der FGV. Will damit nicht sagen das die Idee schlecht ist; im Gegenteil, so kann man gut eine begrenzte Zahl an "Informationen" / Startparametern in den VIs verteilen bzw. zur Verfügung stellen. Nur löst die halt nicht wirklich das Problem Skalierbarkeit. Da würde man sich dann eher nen System anbieten, dass möglichst unabhängig von der Bezeichnung ist.
An sich (habe noch nicht damit gearbeitet) scheint da doch fast das Actor framework die passende Lösung für das Problem zu sein. Soweit ich das überblicke ist da doch grade die Idee, dass jedes Objekt als Akteur gehandhabt wird, mit dem man reden kann (intern über Queues). Die Verwaltung der entsprechenden Verbindungen ist da doch auch schon vereinfacht gehandhabt meines Wissens.
Tl; dr: Die FGV Lösung skaliert meiner Meinung nach genauso schlecht bei vielen Queues (und grad um Skalierbarkeit gings hier ja) wie das anfordern von Queues über einen eindeutigen Namen. Interessant für das eigentliche Problem könnte eventuell auch ein Blick auf das Actor Framework sein.