Queue-Elemente von mehreren Consumern auswerten lassen

' schrieb:Du könntest auch einfach eine 2. oder 3. Queue erstellen, die die Daten einfach weiterreicht/weiterreichen.

Hier ein kleines Bsp., das ich Dir zusammengeklickt habe :

[attachment=45754:Queues.vi]


Gruß Markus

Hey Markus, danke für den Hinweis. Ich werde es so in der Art machen mit einer kleinen Änderung:

Queues von "1 nach 2" und von "1 nach 3" damit hat man die Reihenfolge der Bearbeitung weiterhin variabel eben so wie es grade zeitlich passt. sonst hätte man ja auch irgendwie alles hintereinander programmieren können.

LG
Torsten

Anzeige

Wenn es immer um die gleichen Daten geht, dann gebe ich Dir Recht. Es kann aber auch sein, dass die zweite Schleife aufgrund eines speziellen Befehls der ersten Schleife irgendwas ganz anderes (unabhängiges) an die dritte Schleife schicken soll. Dann solltest Du es so machen. Aber mit den Queues ist man ja flexibel. Da kann mal alles nach seinen Anforderungen anpassen.
Hauptsache es läuft.

Gruß Markus

' schrieb:...
Hauptsache es läuft.
...

Naja, also ich als ausgebildeter und studierter Softwareentwickler habe da schon andere Ansprüche! Es soll auch noch sauber implementiert sein, sprich keine zu hohe/überflüssige Speicherbelastung und so.

Ich geb' Dir ja Recht.....

Gruß Markus

' schrieb:Naja, also ich als ausgebildeter und studierter Softwareentwickler habe da schon andere Ansprüche! Es soll auch noch sauber implementiert sein, sprich keine zu hohe/überflüssige Speicherbelastung und so.

Mein weiterer Vorschlag wäre User Event zu benutzen, da kannst du ein Event generieren und alle für diesen Event angemeldeten Event Strukturen werden gleichzeitig benachrichtigt.

wo wäre denn da der unterschied zu einem melder?

Anzeige

Wäre es eine Alternative, bevor neu geschrieben wird ein rendezvous zu vereinbaren? wenn also alle consumer am rendezvous teilnehmen und bevor ich ein neues datenpaket schicke warte bis alle da sind. ach keine ahnung irgendwie ist das dann auch ein melder. ich blick die unterschiede einfach noch nicht so richtig.

' schrieb:Wäre es eine Alternative, bevor neu geschrieben wird ein rendezvous zu vereinbaren?

Bei all diesen Überlegungen und Alternativen ist meines Erachtens nach die grundlegendste erste Überlegung außen vor geblieben. Die Frage nämlich: Ist die Anwendun so zeitkritisch und/oder die Gefahr eines Datenverlustes so hoch, daß es unbedingt eine Queue sein muß und nicht ein Melder?
Von den meisten Experten hier im Forum werden immer grundsätzlich Queues statt Melder empfohlen, unabhängig davon um welche Anwendung es sich handelt. Von daher wundert es mich nicht, daß hier Melder überhaupt nicht ernsthaft dikutiert werden, sondern statt dessen skurrile Vorschläge gemacht werden, wie man das Problem auch mit Queues auf die Reihe bekommen könnte.
Nichts gegen diese Vorschläge, aber bitte erst, nachdem - und nicht bevor - geklärt ist, daß es nicht ganz normal auch mit Meldern geht.

Wie gesagt, ich blicke noch nicht so ganz die unterschiede/vor-/nachteile von all diesen dingen wie queues, melder, rendevouz, occurences, benutzerevents. Das habe ich alles noch nicht so ganz verinnerlicht (ich kann mit allen dingen umgehen und ne lösung bauen, aber was da optimal ist und was man wann wie einsetzen sollte????).

Ich denke ich werde einfach mal lesen lesen lesen und hoffentlich was lernen und nachher ein gutes ergebnis haben.

Wenn du ausschliesslich unter Windows arbeitest, dann kannst dir mit TLs aushelfen.
Jeder Consumer der von der gleichen Queue die gleiche Status-Message lesen soll muss dabei eine TL sein.
Fuer die TLs erzeugst du dann eine user timing source und tickst programmatisch eine schleife nach der anderen, nachdem der consumer die nachricht gelesen und wieder in die queue zurueck geschrieben hat (opposite end).

Die andere alternative waere mit user events zu arbeiten und jedem consumer mit einer eventstruktur zu realisieren. Entweder ne kombi aus event und queue oder rein event.