Pausieren von parallel ablaufenden Producer/Consumer Schleifen

Hallo miteinander,
in den nächsten Tagen werde ich mit einem Producer/Consumer-Projekt beginne und plane gerade meine Programmstruktur mittels Multicoreprozessor.
Folgendes wird prgrammiert:
Über Prozessor 1 nehme ich Daten auf, die ich in eine Queue schreiben werde (werden große Datenmengen)
Prozessor 2 muss diese Daten zwischenverarbeiten
Prozessor 3 soll für die abspeicherung in Binärfiles zuständig sein.
Dafür möchte ich 3 parallel ablaufende Timed-loops verwenden, um die unterschiedlichen Prozessorkerne verwenden zu können.

Die Messungen sollen dabei ohne personelle Überwachung prakatisch beliebig lange ablaufen können (über Nacht ist standard).
Jetzt sehe ich ein Problem auf mich zukommen:
Tendenziell kann Prozessor 1 schneller Daten aufnehmen, als Prozessor 2 verarbeiten kann - zumindest ist das im Bereich des Möglichen - und damit kann über lange Zeiträume gesehen die Queue langsam vollaufen. Genau das möchte ich nun vermeiden und hier kommt nun meine Frage:
Wie schaffe ich es, abhängig von der Anzahl der Queueelemente bzw. Speicherbelegung der Queue (in MB) , Prozess 1 (Datenaufnahme) pausieren zu lassen so dass Prozess 2 erstmal die Daten weiter verarbeiten kann? Ich würde auch, sobald die Pause-Bedingung eintritt, solange warten wollen, bis Prozess 2 die Queue vollständig abgearbeitet hat. Das ganze am besten ohne lokale Variablen oder an ähnlichen Quatsch. Ich will das richtig sauber programmieren.
Leider hab ich noch keine Codefragmente erstellt und kann daher nix mit anhängen.
Hat jemand eine Idee? Sehe ich den Wald vor lauter Bäumen nicht?

Dank und Gruß
Karl

Hi,

so mal in den Raum gesagt: Schleife für Prozessor 1 mit einer 3-State-Machine ausstatten: 1. State Queue testen, wie voll sie ist, 2. Wait, 3. Daten aufnehmen. In STate 1 entscheidest Du entweder, ob du wartest oder ob du in den Daten aufnehmen-Case gehst, Wait springt immer in den Testen-Case und Daten aufnehmen nimmt immer nur feste Paketgrößen auf udn springt danach wieder in Case 1...

ch

' schrieb:so mal in den Raum gesagt: Schleife für Prozessor 1 mit einer 3-State-Machine ausstatten: 1. State Queue testen, wie voll sie ist, 2. Wait,

Nicht, dass sich die Daten auf diese Weise dann plötzlich im FIFO Puffer der Karte stauen, anstatt in der Queue. Da wäre dann der Queue Puffer die deutlich bessere Alternative, da um Welten größer ...

An Aleph1: Mach erstmal dein Programm so wie du es vorhast. Dann sehen wir ob sich was staut oder nicht. Prinzipiell hört sich dein Konzept sehr gut an.

Edit: Ich bin jetzt mal von Hardwaretakt ausgegangen, weil von großen Datenmengen die Rede ist ...

' schrieb:Wie schaffe ich es, abhängig von der ... Speicherbelegung der Queue ... , Prozess 1 (Datenaufnahme) pausieren zu lassen so dass Prozess 2 erstmal die Daten weiter verarbeiten kann?

Genau so: Kucken, wie viele Elemente in der Queue noch Platz haben (oder schon drinnen sind) ...

' schrieb:Edit: Ich bin jetzt mal von Hardwaretakt ausgegangen, weil von großen Datenmengen die Rede ist ...

Pausieren (siehe oben) im Sinne des Anwenders würde dann heißen, dass der Hardwarepuffer zwar ausgelesen wird - aber nicht per Queue verschickt.

Solange das Problem besteht, dass die Messwerterfassung über Zeit gesehen schneller geht als deren Verarbeitung (wie auch immer: ob zwischenverarbeitet und dann gespeichert oder gestreamt gespeichert), muss man immer mit Verlust in Prozess 1 rechnen - sprich pausieren.

' schrieb:Pausieren (siehe oben) im Sinne des Anwenders würde dann heißen, dass der Hardwarepuffer zwar ausgelesen wird - aber nicht per Queue verschickt.

Aha, und wo warten dann die ausgelesenen Daten in der Pause? Auf dem Pausenhof und essen ihr Pausenbrot? Sprich noch ein Puffer?

Ohne ein Programm finde ich es etwas früh darüber zu spekulieren ob die Verarbeitung zu lange dauert, zumal soviele Kerne im Spiel sind.

' schrieb:Aha, und wo warten dann die ausgelesenen Daten in der Pause? Auf dem Pausenhof und essen ihr Pausenbrot? Sprich noch ein Puffer?

Die warten nicht, die gehen verloren ...

Zitat:darüber zu spekulieren ob die Verarbeitung zu lange dauert

Meine Überlegungen beziehen sich nicht auf ein Ob, sondern auf ein Dass.

Da fällt mir gerade ein:
Auch wenn die Prozesskette zu langsam ist, muss sich Prozess 1 eigentlich um gar nichts kümmern: Einfach in die Queue reinschreiben. Wenn die Queue bereits voll ist, wird der letzte Puffer einfach ignoriert und geht automatisch verloren.

Pausieren kann natürlich auch heißen, die Messwertgenerierung zu stoppen. Das geht dann natürlich wieder wie bei chrissyPu.

Anzeige

' schrieb:Da fällt mir gerade ein:
Auch wenn die Prozesskette zu langsam ist, muss sich Prozess 1 eigentlich um gar nichts kümmern: Einfach in die Queue reinschreiben. Wenn die Queue bereits voll ist, wird der letzte Puffer einfach ignoriert und geht automatisch verloren.

Ich wollte gerade etwas Ähnliches schreiben, aber IchSelbst gab bereits die ultimative Antwort - alles weitere Diskutieren ist damit überflüssig. Nur kleine Ergänzung: "Automatisch" geht nichts verloren. Man muß zum Reinschreiben schon die Funktion "Element einfügen (verlustbehaftet)" verwenden und nicht die ansonsten übliche Funktion "Element einfügen" Die erstgenannte Funktion gibt es erst seit kurzem, also vielleicht ab V8.6. - Es könnte auch Sinn machen, wenn die Daten einen Zeitstempel tragen, damit man merkt, wenn in der ansonten äquidistanten Folge Werte fehlen.

Hallo miteinander,
danke euch schon mal für eure guten Vorschläge.
Was mit den Daten in der eventuellen Pause geschieht, soll mir grad mal egal sein.
Man könnte ja auch, je nach gewünschtem Anwendungszweck Optionen schalten

Messkarte auslesen und neue Daten wegwerfen bis Queue leer
oder
Neue Messdaten als letztes Element in die Queue schreiben und den letzten Wert verlieren.

Aber das soll mich jetzt mal nicht kümmern.
In so fern ist der Vorschlag mit der Statemaschine aber sehr gut zu gebrauchen, der macht ja genau das mit dem "warten bis..."
Bis ich euch ein Programm zeigen kann, dauerts wohl noch a bissl, aber nur so weit: Ich gehe momentan davon aus, dass die datenzwischenverarbeitung (wird eine Art Datenkompression) langsamer vonstatten geht, als die Datenaufnahme, die ich eigentlich beliebig schnell machen kann (hängt nur von der Bitrate der A/D-Wandlerkarte ab, und da gibts sehr schnelle). Die Zwischenverarbeitung der Daten brauch ich, da ich solche Datenmengen nie auf ner Festplatte speichern kann. Mehr zu erklären wär grad zu viel.
Und wenns geht, würde ich schon gern ein paar Megasample/s durch mein System jagen.

Gruß und Danke nochmal
Karl

' schrieb:Die Zwischenverarbeitung der Daten brauch ich, da ich solche Datenmengen nie auf ner Festplatte speichern kann.

Mach dich mal schlau: In LV90 (oder schon 86?) gibt es ein TDMS-Streaming auf DAQmx-Ebene!

' schrieb:Mach dich mal schlau: In LV90 (oder schon 86?) gibt es ein TDMS-Streaming auf DAQmx-Ebene!

http://zone.ni.com/devzone/cda/tut/p/id/9574