Hallo,
habe bislang mit threads noch nichts programmiert, deshalb suche ich mal Anregungen zur möglichen Vorgehensweise im konkreten Fall. Ich hoffe ich kann mich halbwegs verständlich ausdrücken.

Ich habe eine Anwendung mit Tages-Kalender (ähnlich wie Outlook, allerdings 1min Stufung), der auch alle 60s aktualisiert werden soll. Bedeutet u.a., dass die Zeitskala jede Minute nach oben rutscht. Außerdem wird die aktuelle Anwendungszeit (nicht identisch mit realer Zeit) in der Statuszeile angezeigt.

Die Einträge für den Kalender kommen aus TLists. Diese werden periodisch (derzeit noch seriell) durch xml-Abfragen über den TCPClient gefüllt. Dabei habe ich zuerst eine primäre Abfrage, und dann zwei Detailabfragen, die sich auf IDs aus der Primärabfrage beziehen (unterschiedliche xml-Anfragen, lassen sich also nicht zusammenfassen).

Bei kleineren Umgebungen funktioniert das (wie immer) auch sehr gut. Bei größeren dauern die Abfragen und das anschließende Parsen (und notwendige Manipulieren) der xml-Ergebnisse mit zunehmender Laufzeit jedoch immer länger (es werden halt immer längere Listen, die abzuarbeiten sind). Dadurch hängt in der Zwischenzeit die Aktualisierung des Kalenders (tw. 3-4min, hohe CPU-Last).

Nun habe ich die Idee, alle 3 Abfragen in threads auszulagern, damit der Kalender trotzdem aktualisiert werden kann. Zudem könnten aus meiner Sicht die beiden Detailabfragen parallel erfolgen und geparst werden. Also zuerst ein Primär-Thread, und wenn der beendet ist dann parallel 2 Sekundärthreads. Wenn die Abfragen alle durch sind, z.B. 30s warten, dann das ganze von vorne.

Denkt Ihr, dass das eine mögliche Vorgehensweise wäre? Müsste ich dann mehrere TCPClients definieren? Hierbei gibt es noch das Problem (?), dass ich mich erst beim Server registrieren muss (auch per xml-API), bevor er mir irgendwelche Daten liefert.
Es geht mir hier eher um grundsätzliche Ansätze als konkrete Umsetzungen; das wäre dann eh meine Hausaufgabe

Vielen Dank
Frank.