+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Ideen/Meinungen zu modularem Programmaufbau (/Thread-Ideen-Meinungen-zu-modularem-Programmaufbau)
Ideen/Meinungen zu modularem Programmaufbau - Kasi - 20.03.2013 08:38
Hallo liebe Strippenzieher,
in meinem neuesten Mess-Projekt will ich mal eine Thematik umsetzen, an die ich mich bisher nur sehr vorsichtig rangewagt habe: ein "modularer" Programmaufbau.
Einfach gesagt stelle ich mir darunter vor, dem Nutzer eine Fernbedienung, das main vi, vorzugeben, von dem aus er die Möglichkeit hat, verschiedene Programmaspekte (Einstellungen, Messungen und Auswertungen) als separate Fenster aufzurufen.
Die Main soll hierbei als zentraler Knotenpunkt dienen, welche die gesamten Projektdaten enthält und außerdem auch die Kommunikation mit und zwischen den Modulen ermöglicht.
[attachment=44029]
Die Kommunikation und der Datentransfer zwischen den Modulen will ich momentan mit Referenzen erledigen. Jedes Modul bekommt eine Referenz auf die Projektdaten des Hauptmoduls, um so Daten aufzurufen, (signalisierend) zu ändern. Das funktioniert soweit in den ersten Tests auch sehr zufriedenstellend.
Meine Frage nun dazu:
Ich sehe ein größeres(?) Problem bzgl. Race-Conditions auf mich zu rasen (haha), d.h. dass ich ab einer gewissen Parallelisierung der Module nicht mehr gewährleisten kann, dass ein Modul gerade die frisch geänderten Daten eines anderen Moduls überschreibt - wie kann ich diesen Fall verhindern, bzw. mein Design verbessern?
Danke für eure Meinungen,
Grüße,
Kasi
RE: Ideen/Meinungen zu modularem Programmaufbau - A.Berndsen - 20.03.2013 09:05
Hallo Kasi,
(20.03.2013 08:38 )Kasi schrieb: ... d.h. dass ich ab einer gewissen Parallelisierung der Module nicht mehr gewährleisten kann, dass ein Modul gerade die frisch geänderten Daten eines anderen Moduls überschreibt - wie kann ich diesen Fall verhindern, bzw. mein Design verbessern?
ich denke das ist der Anwendungsfall für Semaphoren. Du überprüfst und setzst eine Semaphor bevor Daten bearbeitet werden. Ein weiterer Prozeß, überprüft ebenfalls die Semaphore und bearbeitet die Daten in diesem Fall nicht, erst wenn die Daten wieder freigegeben sind.
Alternativ könnte ich mir auch eine Actionengine vorstellen, in der die Daten gehalten werden.
Grüße
Andreas
RE: Ideen/Meinungen zu modularem Programmaufbau - Lucki - 20.03.2013 11:01
Wozu überhaupt Parallelisierung der Module? Ich sehe da einen Widerspruch zwischen deinem Text und deiner Graphik.
Graphik: Du rufst z.B. Modul Messung 1 auf. Erst wenn das beendet wird, ist das Hauptmenü wieder zugängig und es kann von da aus ein anderes Modul angewählt werden. usw.
Die ganzen Datenverwaltungs- Wettlauf- und Synchronisationsprobleme gibt es ja erst beim parallelen Laufen der Module. Welchen Vorteil würde Dir das denn bringen? Und was ist denn der genaue Unterschied sein zwischen Parallelisierung und "einer gewissen Parallelisierung"? Ist das Letzgenannte so etwas wie Ähnliches wie "ein bisschen schwanger" ?
RE: Ideen/Meinungen zu modularem Programmaufbau - BNT - 20.03.2013 13:24
Hi Kasi
Denk doch mal über den Einsatz des NI Actor Frameworks nach.
Gruß Holger
RE: Ideen/Meinungen zu modularem Programmaufbau - Kasi - 20.03.2013 14:53
Erstmal vielen Dank für das zahlreiche Feedback
@ Lucki:
Zitat:Graphik: Du rufst z.B. Modul Messung 1 auf. Erst wenn das beendet wird, ist das Hauptmenü wieder zugängig und es kann von da aus ein anderes Modul angewählt werden. usw.Sorry, falls die Grafik missverständlich war, die Pfeile symbolisieren nur die Kommunikation, nicht den Ablauf. Messung 1 kann durchaus laufen, während man parallel die bereits die Auswertung ansieht und durch Parameter entsprechend variiert.
Zitat:Und was ist denn der genaue Unterschied sein zwischen Parallelisierung und "einer gewissen Parallelisierung"? Ist das Letzgenannte so etwas wie Ähnliches wie "ein bisschen schwanger" ?Ich wollte damit zum Ausdruck bringen, dass nicht alle Module zu jeder Zeit etwas in die Daten schreiben können, so dass nur manche Module echtes "Konfliktpotential" haben. Aber der Einfachheit halber hätte ich wohl lieber einer nur "Parallelisierung" sagen sollen.
@ Andreas:
Zitat:ich denke das ist der Anwendungsfall für Semaphoren. Du überprüfst und setzst eine Semaphor bevor Daten bearbeitet werden. Ein weiterer Prozeß, überprüft ebenfalls die Semaphore und bearbeitet die Daten in diesem Fall nicht, erst wenn die Daten wieder freigegeben sind.So ein Ampelsystem ist natürlich wirklich eine sinnvolle Lösung des Problems - hab ich noch nie mit gearbeitet, bietet sich hier aber an.
Zitat:Alternativ könnte ich mir auch eine Actionengine vorstellen, in der die Daten gehalten werden.Auch eine Idee, werde mich aber erstmal am Semaphor versuchen.
@ BNT
Werde ich machen. Sobald ich über die passende LabVIEW-Version verfüge.