Der Thread sollte gar nichts mit der Oberfläche zu tun haben sondern nur die jeweils aktuellen Daten bereitstellen. Wenn es neue Daten gibt, kann er ja ein Event auslösen und die Oberfläche zeigt die jeweils aktuellen Daten an wie sie grade Lust hat.
emm... nix anderes ist ein Syncronize... Ob Du nun wie Du im Beispiel den Event im Queue auslößt oder mit Sync es aus dem Thread selber machst... Ich erstmal "fast" kein Unterschied...
Bringt Queue() neben dem Vorteil, dass der Threadablauf nicht blockiert wird, irgendwelche Nachteile mit sich?
Man muss sich im klaren sein was wann passiert...
Beispiel für Queue aus dem Thread oder wie Günther es geschrieben hat ein Event dann die Daten von der anderen Seite aus holt...
Beispiel:
Ein Thread erzeugt permanent Daten und zwar nicht nur ein Integer sonst was kompliziertes...
Bei einem Syncronize musst du zwar warten auf den UI-Thread aber kannst sicher danach die Daten verwerfen...
Bei ein Queue Aufruf, musst Du sicher stellen, dass zum Zeitpunkt wo der UI-Thread die Daten darstellen will, die Daten auch noch vorhanden sind. Noch schwieriger ist es, wenn Du die Kontrolle - wie Günther - an ein anderes Programmteil übergeben hast... Denn falls der UI-Thread die Daten lesen will, muss sichergestellt werden, dass der Thread die Daten nicht gerade neu- oder überschreibt.
Musst Du alle Zwischenschritte immer darstellen? Ich habe hier z.B. eine Routine programmiert, die immer wenn der Thread neue Daten erzeugt und der UI-Thread die Daten noch nicht verarbeitet hat, der letzte Datensatz verworfen und sofort gegen den neuen Ausgetauscht wird.
Für Dein Problem, würde ich einfach 2 oder wie viele auch immer Du brauchst eigenen Threadsichere Queues erzeugen und diese über einen Workerthread der gemäß Priorität die einzelen Queues abarbeitet und dann problemlos Syncronisieren kann.
Mavarik