Ich hab das erst jetzt gelesen, weil in einem anderen Thread darauf verwiesen wurde und muss da (leider, ich hoffe zu verzeihst mir Lucki) da nochmal drauf eingehen:
<klugscheiss>
' schrieb:Ich weiß jetzt also nicht, wie es in den Vorversionen war, aber für LV8 kann ich sagen: Melder und Queues sind bezüglich der Datentypen völlig identisch, man kann jeden Datentyp, den man mit einer Queue übertragen kann, genau so mit einem Melder übertragen. Auch die gesamte Funktionspalette für Melder und Queue ist weitgehend identisch
soweit stimme ich zu
' schrieb:(oder besser, weil Queues komplexer sind: Die Funktionen für Melder sind eine Untermenge der Queue-Funktionen).
falsch! Queues sind Queues und Notifyer sind Notifyer. Es sieht zwar ähnlich aus und man kann ähnliche Dinge damit anstellen, aber die beiden Systeme sind
grundsätzlich verschieden! Ein Notifyer ist eine
per se verlustbehaftete Möglichkeit Daten von einem Sender zu einem Empfänger zu übertragen. Wenn der Sender die Nachricht nicht rechtzeitig abholt kann diese von der darauffolgenden Nachricht überschrieben werden. Wenn man das an einem Beispiel festnageln möchte: Stell dir eine DruckerQ vor, die nicht als Q sondern als Notifyer angelegt ist. Diese wird immer nur das zuletzt abgeschickte Dokument drucken. Solange die Sender so langsam senden, dass alles zwischen zwei Sendungen erledigt werden kann, ist das kein Problem, aber sobald die Druckaufträge schneller gesendet werden als der Drucker drucken kann, gehen Druckaufträge verloren.
' schrieb:Deshalb würde ich sagen, daß wegen der größeren Einfachheit Melder in jedem Fall die bessere Alternative zu Queues mit Warteschlangenlänge 1 sind. Ich würde sogar so weit gehen zu sagen, daß in den meisten Fällen, in denen hier im LVF eine Queue empfohlen wurde, ein Melder die bessere Empfehlung gewesen wäre, weil es fast immer nur um die Kommunikation zwischen VIs geht, nicht aber darum, zwischen Sender und Empfänger außerdem noch eine Warteschlenge aufzubauen.
Eine Q ist eine Warteschlange - analog zu einem First In First Out Puffer. Die Begrenzung der Anzahl der Elemente in einer Q hat den Hintergrund, dass man beim
SENDER durch die entsprechende Fehlermeldung darauf hingewiesen werden kann, dass die Q voll ist - und dann entsprechend Reagieren kann. Die Aussage, dass ein Notifyer für die Steuerung einer Statemachine mit Producer und Consumer Loop das Mittel der Wahl wäre ist somit falsch, weil ggf. - wenn die Consumer-Loop "zu lange" - braucht Aktionen (z.B. Klicks auf Buttons) verloren gehen.
' schrieb:Aber jetzt geht mir ein Licht auf, die Vorliebe für Queues hat also ihre historischen Wurzelen, weil früher in bezug auf die Datentypen Melder nicht so viel konnten wie Queues.
auch nicht. Die Vorliebe für Qs hat ihr Wurzeln darin, dass sie die einzig zuverlässige Methode zur zeitlich korrekten Abarbeitung von Events in einer Statemachine sind.
</klugscheiss>
