' schrieb:Schiebe dein Objekt nach der Erzeugung einfach in eine Single Element Queue. Schreibe dir ein Checkin und ein Checkout VI, welches das Objekt aus der Queue herausholt und wieder hineinschiebt. Solange das Objekt ausgecheckt ist kann der zweite Thread nicht darauf zugreifen. Vorteil: Du hast einen gegenseitigen Auschluss und Raceconditions vermieden.
Naja, das ist aber auch nur das eine von zwei Übeln (Das andere Übel sind die FGVs).
Der Vorteil von LV gereicht hier zum Nachteil: Wenn ein Datensatz, ob abgelegt in FGV, Queue oder Klasse, sich wegen Bearbeitung gerade in einem Datenfluss befindet, so darf der Datenfluss solange nicht gestört werden, bis der Datensatz wieder abgelegt ist (in FGV, Queue oder Klasse). Dumm nur, dass LV per se ein Multitasking-System ist (jede While-Schleife eine Task), das es dem Anwender leicht macht (bis hin zu: er merkt es gar nicht), die Datenflüsse in anderen Tasks zu stören (fatale Folge wäre RaceCondition).
Die Queue-Methode ist einfach zu durchschauen: befinden sich die Daten der Queue zwecks Bearbeitung in einem Datenfluss - sind sie nicht mehr in der Queue und somit für jeden anderen nicht "störbar". FGVs sind eine Stufe komplizierter: Die Bearbeitung findet innerhalb des FGVs-SubVis statt. Da während der Bearbeitung das SubVI nicht noch ein zweites Mal ausgeführt werden kann, stellt auch das eine sichere Methode dar. Man darf natürlich nicht die zu bearbeitenden Daten aus dem SubVI herausgeben, bearbeiten und wieder hineingeben. Dann ist ein Datenfluss vorhanden, der von extern störbar ist (= RaceCondition).
Am liebsten hätte man natürlich eine Klassen-Instanz, die prinzipiell funktioniert wie eine FGV: Solange eine Instanz arbeitet, kann sie von niemand anderem Arbeit entgegennehmen.
Ich bleibe vorerst bei meinen FGVs. Die reichen für meine Belange bisher vollkommen aus.