Reentrance

' schrieb:Was passiert wenn ich ein reentrantes VI schneller aufrufe, als das VI ausgeführt wird?

wenn das VI in einen Datenfluss eingebunden ist, z.B. in einer while Schleife und ein error-Cluster rein und raus geht, dann passiert nichts weiter, d.h. die Geschwindigkeit des reentranten VIs würde ggf. die Schleifen-Geschwindigkeit bestimmen.

Wenn du ein reentrantes VI über VI Server aufrufst und du das VI schneller aufrufst, als das VI für die Abarbeitung braucht, dann müllst du dir so lange den Speicher zu, bis LabVIEW aufgibt. Beispiel: dein reentrantes VI braucht 10 Sekunden für eine Berechnung, du rufst aber jede Sekunde eine neue instanz auf, dann ist bald Schicht im Schacht

Grüße
CB

' schrieb:Wenn du ein reentrantes VI über VI Server aufrufst und du das VI schneller aufrufst, als das VI für die Abarbeitung braucht, dann müllst du dir so lange den Speicher zu, bis LabVIEW aufgibt. Beispiel: dein reentrantes VI braucht 10 Sekunden für eine Berechnung, du rufst aber jede Sekunde eine neue instanz auf, dann ist bald Schicht im Schacht

Genau das, was ich wissen wollte. Danke

NAbend,
das mit dem zumuellen hat nur bedingt seine Richtigkeit.
Denn du kannst per VI Server auch einen Option Aufruf mittels 0x08 machen, was bedeutet, dass nach dem abarbeiten des zeitablaufinvarianten VIs der Speicher wieder frei gemacht wird.
D.h. dass in dem konkreten Beispiel der 11. Aufruf des VIs per VI Server wieder den Speicherbereich des 1. VIs verwendet (sofern sich von den Daten nichts geaendert hat).

' schrieb:das mit dem zumuellen hat nur bedingt seine Richtigkeit.

Das sehe ich anders: Das ist nicht nur "nur bedingt richtig" sondern schlichtweg falsch. Das läßt sich leicht nachprüfen. Jedes Ikon eines reentranten VI inerhalb eines Programms ist ein eigener Clon. Wenn es drei Ikons im Programm gibt, dann gibt es diese drei Clones, und nicht mehr. Wenn in einer Schleife, wie das in einer Schleife eben der Fall zu sein pflegt, ein und dasselbe Ikon eines Sub-VIs immer wieder aufgerufen wird, und das Sub-VI ist reentrant und außerdem langsam, dann passiert nichts anderes als bei einem nicht-reentrantes VI: ein neuer Scheifendurchlauf findet erst statt, wenn alles in der Schleife - und dazu gehört auch das reentrante VI - abgearbeitet ist. Von der Erzeugung neuer Clones bei dieser Gelegenheit kann überhaupt keine Rede sein und auch nicht vom Zumüllen des Speichers.
Denselben Efekt wie mit einem reentranten VI erreicht man, wenn man mehrere identisch Kopien des Sub-Vis mit unterschiedlichem Namen erzeugt und jede Kopie im Programm nur ein mal verwendet. Nachteile hätte das nur bei der Versionspflege und im größeren Speicherbedarf auf der Harddisk.


Wann sind reentrante Sub-VI sinnvoll oder sogar notwendig?
Fall 1:
In eine Schleife laufen 10 identisch Sub-Vi parallel, und in jedem Sub-Vi gibt es Wartezeiten. Bei normalen SUB-Vi ist die Schleifendurchlaufzeit (wenn man mal die sonstigen zeiten vernachlässigt) gleich der Summe aller Wartezeiten, bei reenranten VI ist die Schleifendurclaufzet nur gleich der längten dieser 10 Zeiten
Fall 2:
Wenn das Sub-Vi nicht initialisierte Schleifen hat, dann braucht jedes Ikon seinen eigenen Datenbereich. Beispiel siehe unten: Zwei Punkt-zu-Punkt Tiefpassfilter mit den Zeitkonstanten 10 bzw. 20 Datenpunkten werden parallel betrieben. Wenn das Tiefpass-VI nicht reentrant ist, funktioniert das nicht, weil es insgesmat nur ein Memoryelement gibt. Es braucht aber jeder Filter seinen eigenen Speicher.
Fall 3:
Rekursiver Aufruf eines VI, d.h. Aufruf des Vi abc.vi innerhalb des VI abc.vi. Das kenne ich allerdings nicht aus eigener Praxis, aber hier - und nur hier - kann man sich ein Zumüllen des Speichers tatsächlich denken, bei entsprechender Tiefe der Rekursion.

' schrieb:Das sehe ich anders: Das ist nicht nur "nur bedingt richtig" sondern schlichtweg falsch.

nö, ist es nicht. Ich präzisiere meine Aussage nochmal:

- das 10 Sekunden Beispiel ist falsch, wie Freedive bereits angemerkt hat, richtig ist:
Wenn man mittels VI Server reentrante VIs schneller aufruft, als sie abgearbeitet werden, dann müllt man sich den Speicher zu. So lange es bei einer definierten maximalen Anzahl von Instanzen bleibt, ist das kein Problem. Problematisch kann es werden, wenn man keine Kontrolle mehr über die Anzahl der Instanzen hat. Bei meinem 10 Sekunden Beisiel hätte man immer nur 10 Instanzen im Speicher => kein Problem.

Wenn man meherere Instanzen eines reentranten VIs z.B. in einer while-Schleife aufruft, dann gilt natürlich das Datenflussprinzip (hatte ich schon erwähnt ...), welbst wenn die VIs *in der Luft hängen*, da *kann* man nicht in die Gefahr laufen, dass man den Speicher zumüllt.

Und wenn man die Posts mal genau durchliest, dann meinen wir glaub ich alle das gleiche

grüße
CB

' schrieb:Und wenn man die Posts mal genau durchliest, dann meinen wir glaub ich alle das gleiche

Ja, ich hatte überlesen, daß Du das Zumüllen auf VI-Server eingeschränlt hattest, und da kenne ich mich überhaupt nicht aus und hätte besser den Mund handeln sollen.
Was ich meinte, ist, daß in den anderen diskutierten Fällen, bei Verwendung eines reentranten Sub-VIs, ein "Zumüllen", wenn man das überhaupt so nennen mag, nur pro zusätzlich platziertes Ikon stattfindet. Es gibt nur so viel Clones, wie es Vis gibt. Es besteht also keine Gefahr, daß während der Laufzeit des Programmes immer wieder zusätziche Clones von selbst entstehen.

Ich habe mal ein Spielprorgramm gemacht, um den Unterschied bei der parallelen Abarbeitung in einer Schleife zu demonstrieren. Die Sub.Vis haben Wartezeiten von 600,700,800,900 ms, und erzeugen dann einen Ton von 50ms, Tonhöhe gleich Zahlenwert der Wartezeit. In dem einen Fall braucht ein Schleifendurchlauf 600+700+800+900 ms, im anderen Fall nur 900ms.

Übrigens: Das dämlichste, was man mit einem reentranten VI machen kann, ist, damit auf ein und dieselbe Hardware mehrere Male zuzugreifen. Denn Hardware hat die dumme Eigenschaft, daß sie sich nicht mit klont, und da sind Konflikte vorprogrammiert.

Anzeige

' schrieb:Was ich meinte, ist, daß in den anderen diskutierten Fällen, bei Verwendung eines reentranten Sub-VIs, ein "Zumüllen", wenn man das überhaupt so nennen mag, nur pro zusätzlich platziertes Ikon stattfindet. Es gibt nur so viel Clones, wie es Vis gibt. Es besteht also keine Gefahr, daß während der Laufzeit des Programmes immer wieder zusätziche Clones von selbst entstehen.

jau, da stimm ich zu

' schrieb:Übrigens: Das dämlichste, was man mit einem reentranten VI machen kann, ist, damit auf ein und dieselbe Hardware mehrere Male zuzugreifen. Denn Hardware hat die dumme Eigenschaft, daß sie sich nicht mit klont, und da sind Konflikte vorprogrammiert.

da auch ... man könnte jetzt natürlich was konstruieren, dass es trozdem geht. z.B. könnte man das reentrante VI über Semaphoren absichern, etc, aber mir fällt jetzt keine wirklich sinnvolle Anwendung ein, wo man das bräuchte, bzw. nicht mit einer Funktional Global erschlagen könnte

Grüße und schönen Sonntach,
CB