Hallo liebe VEE´ler!

Meine Frage ziehlt auf die neue Verfügbarkeit von ThreadObjects in der Version 9 ab.

UserFunctions haben den Vorteil, dass sie einmal geändert, diese Änderungen in jedem Aufruf gelten. Spart Zeit und Speicher. Spart es auch Zeit?

UserObjects haben ihre Berechtigung in der schnellen Übersichtlichkeit (was UserFunctions und ThreadObjects auch haben)

ThreadObjects sollen "parallel" also schneller laufen. Aber irgendwie bekomme ich da einen handling-Fehler (irgendwas mit marshall) Das werde ich dann nochmal testen. Vorerst aber noch eine andere Frage:

In der Hilfe gab es keine Übersicht, wann man was nutzen sollte.
Ich baue derzeit hauptsächlich auf UserFunctions auf. Wollte aber ThreadObjects testen, aus folfgenden Grund (vielleicht gibts ja auch eine andere Möglichkeit das zu realisieren):

Ich habe 2 Messgeräte, die parallel messen sollen. Das Gerät A braucht für eine Messung deutlich länger als Gerät B. Also während A einmal misst, kann B zehn mal messen. Genauso soll es auch sein. Allerdings blockiert das Messen mit Gerät A Vee solange, da es ja auf eine erfolgreiche Ausführung der Funktion wartet. Die Messaufrufe sind UserFunctions.

Wie bekomme ich es hin, dass während dieser Messung Gerät B mehrmals misst?

Grüße
Friedbert

Hallo Friedbert,
also ich würde sagen dass du einfach die Messungen in unterschiedliche ThredObjects verfrachtest. Dann sollte es parallel ablaufen.
Ich bin aktuell auch mit ThreadObjects am rumprobieren. Bekomme aber immer eine Speicherzugriffsverletzung(Error:979) Ich glaube das liegt daran dass ich 2 Threads habe, die auf die selben Variablen zugriefen...
Hat viellt jemand schon mehr Erfahrungen mit den ThreadObjects??
Grüße
loki

Ich habe die Threadobjekte nicht in den Messablauf integrieren können bzw. die einzelnen Messungen in Threadobjekte auslagern können.
Die eine Messung wird dann nicht ausgeführt, aber als UserFunction geht es.
Ich habe jetzt beschlossen vorerst bei der alten Methode zu bleiben und beim Neuaufbau eines Programms Threadobjekte mit ins Konzept zu nehmen. Denn bei einem einfachen Beispiel klappt es:

In jedes Threadobjekt eine until break schleife mit Zähler. Wenn dann das Programm pausiert wird haben beide Counter einen ähnlichen Wert. aber nachträglich in einem komplexeren Programm... da wird es schwieriger

Friedbert

@loki
du kannst ja mal eine Minimalbeispiel anhängen. Ich bin jedoch der Meinung, dass der lesende Zugriff auf die gleiche Variable kein Problem darstellen sollte.
Schreibend könnte das passieren, wenn der eine Thread die Variable sperrt, während er etwas rein schreibt. Da könntest du eventuell mit Semaphoren arbeiten. Setze im einen Thread vor dem Schreibzugriff eine Variable zum Beispiel bool_busy auf true und nach dem schreiben wieder auf false und frage im anderen Thread ob bool_busy==false ist. Das solltest du in beiden threads machen (vermutlich mit unterschiedlichen bool_busy1 und bool_busy2 ). Wenn false dann schreibe. Vielleicht funktioniert das.

LOL Semaphore natürlich...
Viel Dank!
Es hat funktioniert. Ich stell mal ein Bild von einem Beispiel ein.
MfG
loki
   

Hi,

sorry, hat eigentlich nichts mit dem Thema zu tun, aber wozu benutzt du die Steuersignale so oft? Habe das jetzt schön öfter gesehen. Es reicht doch, wenn nur der Datenausgang zum nächsten Block geht, oder nicht?

z.B. bei "Text" zu "Set test"

Danke schon einmal für die Antwort

Marc, da hast du recht! Das ist nicht sinnvoll. Steuer- bzw. Flussleitungen sollten so wenig wie möglich verwendet werden und bei Bäumen bzw. Threads nur das erste Element des Threads verbinden. Ansonsten riskierten man undefinierte Ausführungen (manche Knoten werden dann nicht ausgeführt oder in falscher Reihenfolge) Hinweise dazu gibt es in der Hilfe von Vee.

Hmm, ja ok beim Text ist das unnötig.
aber ist es denn nicht so, das man durch die Steuerleitungen gerade undefinierte Ausführungen verhindert? z.B. in dem angehangenen Beispiel kommt es bei der Ausführung ohne die Steuerleitungen zu fehlern.
Mit Steuerleitungen geh ich sicher das der komplette Thread für jede Variable einmal ausgeführt wird.
Grüße
loki

   

Danke erst einmal für die Antworten

Korrigiere mich, falls ich falsch liege, aber mormalerweise braucht man auch hier die Steuerleitungen nicht. Schleifen zählen erst hoch, wenn der komplette Pfad am Datenausgang durchgelaufen ist (oder next bzw. break kommt).
Ebenso ist es auch bei der Junction. Sie lässt das nächste Datensegment erst durch, wenn der komplette Pfad durchgelaufen ist.


Habe noch ein paar andere Sachen, die ich an VEE seltsam finde. Dafür mache ich aber ein neues Thema auf

Ja das stimmt...
Schaut mal in der Hilfe zu "Uncertain Data Flow Compiler Warnings" - Compiler Warnings.

Da wird genau erklärt warum und wann Steuerleitungen zu setzen sind und was sie für Probleme verursachen können, wenn sie übermäßig genutzt werden.

Grüße
Friedbert

wieder was dazu gelernt - Danke!!
Habe bei dem Control Input von "To File" nie den Sequenzeingang benutzt
(siehe Hilfe: "Control Input Pins that Carry Data" unter "Understanding Sequence Pins")

loki hatte übrigens trotzdem Probleme?!?

(28.05.2010 13:35)loki schrieb:  Bei mir hat der in meinem Beispiel tatsächlich einen Fehler gemacht: Er hat getVariable ausgeführt bevor ein Name aus den Formularen reinkam. Darum benutz ich die Steuerleitungen immer