Multiprozessor - denken ist notwendig

Hallo,

mit Multiprozessor muss man mitdenken, vor allem wenn man mit Referenzen arbeitet und Indikatoren manchmal Sonderbares anzeigen. Was mir aufgefallen ist:

* Man dreht (+ sonstiges) ein Bild und schreibt es auf ein File - manche Bilder sind NICHT gedreht, da das Drehen++ noch nicht fertig ist wenn man das Bild schreibt - warten hilft klarerweise

* man zeigt ein Bild in einem Indikator. Der Zweig wir NICHT angesprungen (ist in einem false case), aber wnn man das FP verschiebt sieht man auch Bilder die man nicht sehen sollte - die Zeit wo ich durchs Schlüsselloch in der Nacht den Fernseher meiner Eltern beobachtet habe ist schon etwas vorbei...

das ist sicher nicht das Einzige.

Beispiele beziehen sich auf Vision, meine aber das diese "Eigenheiten" nicht visionspezifisch sind

Guten Rutsch ins neue Jahr

Gottfried

Anzeige

Ich wünsche Dir auch einen guten Rutsch.

Gruß Markus

' schrieb:sieht man auch Bilder die man nicht sehen sollte - die Zeit wo ich durchs Schlüsselloch in der Nacht den Fernseher meiner Eltern beobachtet habe ist schon etwas vorbei...

' schrieb:die Zeit wo ich durchs Schlüsselloch in der Nacht den Fernseher meiner Eltern beobachtet habe ist schon etwas vorbei...

1960 schon Fernseher gehabt, ihr wart aber fortschrittlich

Ebenfalls ein gutes 2011.

Gruß, Jens

P.S.: Da das Vision-Image schon immer eine Referenz war,:verschoben12:Deine Bsp können IMHO auch schon bei einem Single-Prozessor passieren. Ein klarer Nachteil des Vision-Pakets, das hier nicht so recht in die LV-Welt des Datenfluss passen will.

> 1960 schon Fernseher gehabt, ihr wart aber fortschrittlich cool.gif

Du bist gemein - Du hast nachgerechnet!

' schrieb:Hallo,

mit Multiprozessor muss man mitdenken, vor allem wenn man mit Referenzen arbeitet und Indikatoren manchmal Sonderbares anzeigen. ..

Das ist denkbar, dass ein Prozessor schon mal versucht Werte anzuzeigen, während der andere noch am Wert berechnen ist.

Wenn ich aber ein SubVI aufrufe kann (sollte?) das nächste SubVI erst ausgeführt werden, wenn das erste fertig ist, vorausgesetzt sie sind durch Drähte verbunden (z. B. Errorcluster).

' schrieb:* Man dreht (+ sonstiges) ein Bild und schreibt es auf ein File - manche Bilder sind NICHT gedreht, da das Drehen++ noch nicht fertig ist wenn man das Bild schreibt - warten hilft klarerweise

Sind die Vision VI über den Error-Cluster verbunden?

Man kann schließlich eine Referenz auf ein bestehendes Bild öffnet mit IMAQ create und der Angabe des richtigen Names. Das könnte obigen Effekt erklären.

' schrieb:* man zeigt ein Bild in einem Indikator. Der Zweig wir NICHT angesprungen (ist in einem false case), aber wnn man das FP verschiebt sieht man auch Bilder die man nicht sehen sollte - die Zeit wo ich durchs Schlüsselloch in der Nacht den Fernseher meiner Eltern beobachtet habe ist schon etwas vorbei...

Ist es ein älteres Bild, das schon mal angezeigt wurden und wieder erscheint?

' schrieb:das ist sicher nicht das Einzige.

Beispiele beziehen sich auf Vision, meine aber das diese "Eigenheiten" nicht visionspezifisch sind
...

Value (signaling) geht wohl gelegentlich auf Mehrkernprozessoren nicht.

' schrieb:Value (signaling) geht wohl gelegentlich auf Mehrkernprozessoren nicht.

Hast du dazu genauere Infos? In den LV Known Issues habe ich dazu nix gefunden.

Anzeige

Nein, nur praktische Erfahrung mit einem langsam wachsenden Programm mit einer Producer-Consumer-Loop, bei dem ich mangels einer State-machine mit Value Signaling gearbeitet habe um den Wirkung einer State-machine umzusetzen. Irgendwann war das Programm so umfangreich, das das Value signaling manchmel klappte und manchmal nicht. Die Erklärung kommt von einem NI Allianz Partner.

Also.....

die ungedrehten Bilder kamen (manchmal) _nach_ dem Dreh-VI wobei die Dinger verbunden waren .... sonst kann man ja das Zeug nicht schreiben (OK eine Global mit der Referenz wäre möglich)

die falschen Bilder kamen am Indikator (ich erinnere) Indikator in einem nicht wirksamen if _nachdem_ die Richtigen gezeigt wurden

Ich denke das sind Randeffekte wenn man eben einen Compiler optimiert: da glaubt eben eine Instanz "das kann ich parallisieren" aber dei Wirklichkeit war anders.

Noch einmal: die VIs flogen nicht in der Luft herum, alles an Drähren und am Errorcluster (hoffe ich :-)

Gottfried

PS.: jetzt wollt Ihr sicher dass ich ein Beispiel aus einem riesigen Projekt herausoperiere .... bitte nein .... bitte glaubt mir.

Wenn das Projekt so komplex ist, dass ein Extrakt zum Hochladen nicht möglich ist, könnte es da eventuell sein, dass das Programm nicht ganz eindeutige Zustände hat? Bei einigen meiner Vision-Programme hat ich vergleichbare Effekte: Bilder wurden nicht angezeigt oder sahen verkehrt aus. Das lag aber meist am Code selbst und irgendwelchen irrtümlichen Annahmen, die ich über das Verhalten des Codes gemacht habe.

Ich bin mir jetzt nicht sicher, ob schon mal der Fall aufgetreten ist, dass ich eine Bild angezeigt habe, dieses danach verändert habe und dann durch FP verstecken und wiederholen o. ä. das Anzeigeelement das geänderte Bild angezeigt hat.

' schrieb:Also.....

die ungedrehten Bilder kamen (manchmal) _nach_ dem Dreh-VI wobei die Dinger verbunden waren .... sonst kann man ja das Zeug nicht schreiben (OK eine Global mit der Referenz wäre möglich)

die falschen Bilder kamen am Indikator (ich erinnere) Indikator in einem nicht wirksamen if _nachdem_ die Richtigen gezeigt wurden

Jens hat es schon einmal angetönt. IMAQ Refnums sind echte Referenzen (Pointer). Das ist zwar sehr LabVIEW atypisch, und daher oft alles ausser intuitiv für einen gestandenen LabVIEW Programmierer, aber die einzige Art um in LabVIEW (und überhaupt in Software) effizient Bildverarbeitung zu machen. Der Unterschied ist nur dass man bei den meisten anderen Sprachen für komplexe Datentypen so oder so mit Referenzen arbeitet und bei LabVIEW halt fast immer mit Values (fast weil es ja in den neusten Versionen auch noch Datenreferenzen gibt).

D.h. wenn Du eine IMAQ Referenz hast und diese nicht explizit deletetest bleibt sie einfach im Speicher (das IMAQ Control hat ja auch noch eine Referenz dazu offen) und obwohl der Code nicht ausgeführt wurde im nächsten Schlaufendurchlauf, siehst Du noch die alten Daten. Auch kann eine Operation auf eine Referenz irgendwo ganz anders im Program das Bild in einem IMAQ Control, dass diese Referenz darstellt urplötzlich veränderen, ohne irgendwelche ersichtliche Datenabhängigkeit.

Das Fehlen von Datenreferenzen in LabVIEW war einer der Gründe dass Multithreadingsupport in LabVIEW relativ einfach einzubauen war (einfach von einem prinzipiellen Gesichtspunkt, nicht unbedingt einfach als technische Herausforderung!). Die Datenflussprogrammierung eignet sich perfekt für Multiprocessing und Multithreading (was wohl bei der Erfindung von LabVIEW kaum ein entscheidender Faktor war:Dsondern eher eine glückliche Fügung).