Hallo, ohne jetzt den Code Complett zu analysieren, versuche doch erst einmal, eine kapselung der beiden klassen Mainform und Thread. Ich sehe hier viele kreuzreferenzen, die es schwer machen, den code zu lesen. Und zu verstehen. Einerseits erstellst du einen thread, startest ihn aber ueber die Mainform. Bedenke, das suspend/resume veraltet sind. Du rufst funktionen im Thread auf, die nicht im Construktor gesetzt werden, sondern wiederrum spaeter in der Mainform... Das ganze ohne Fehlerpruefung. Execute hat viele lokale variablen, versuche auch hier strukturen oder Properties zu verwenden. Ab d2009 koennen Records auch Methoden haben. Das eignet sich sehr gut diese zu initalisieren. Vermeide die globale Variable. Falls unbedingt notwendig, stelle sicher, das der Zugriff nur via criticalsections erfolgt.
Viele Gruesse
Msch

Hi,

hmmm ... also es ist deshalb getrennt vom mainform weil ich es gern vom form entkoppelt habe ... die kreuzreferenzen die du meinst ergeben sich nur aus dem syncen so wie ich das sehe und was ja auch für das sichere handeln des listviews wichtig ist ... also wie ich sehe ist es scheinbar das problem das nicht alle items im listview durch die getnextanalyseitem routine erfasst werden oder als "analysed = true" gehandelt werden .... der zugriff auf den activethreads counter erfolgt auch im gesyncten teil und am ende des durchlaufes bleiben auch 0 threads in counter ... also scheint das auch alles ok ...

ich pack mal den source dazu

So ...

es war mal wieder wie so oft der zu lange blick auf den eigenen source ... ich habe nach allem gesucht aber letzten endes fehlte nur ein setzen des analysed flags in dem Record beim anlegen des datensatzes und des listitems mal schauen wie weit ich nun komme

Bis hierher vielen Dank

Andreas

Das Problem ist an dem Quelltext das Konzept. Du verbandelst da GUI und Daten und Threads fest miteinander. Viel sinnvoller wäre es, wenn du deine Daten separat verwalten würdest, die Threads daran anbinden würdest, und dann die Daten in der GUI nur anzeigen würdest.

Erstens würde es dann viel einfacher werden, da die einzelnen Teile übersichtlicher würden, andererseits auch schneller, da die GUI weniger durch Synchronisierungen warten muss und du einfacher mehrere Threads parallel nutzen kannst. Und außerdem wäre es auch ein saubereres Konzept.

Du meinst also die Analyseergebnisse in einer TList speichern und erst danach anzeigen oder was genau meinst Du ?

Nein, komplett von der TListView losgelöst arbeiten. Du hast eine Liste der aktiven Tasks. Und du synchronisierst die Threads nicht mit dem Haupttthread, sondern benutzt Critical Sections um diese Liste aktuell zu halten. Auf die Weise behindert das die GUI gar nicht.
Bei Änderungen der GUI schickst du deiner GUI z.B. eine Nachricht, eine Windows Message kannst du ja auch ohne Synchronisierung schicken.

Deine GUI empfängt diese Message, ist aber schon im Hauptthread, d.h. auch hier ist keine Synchronisierung nötig, du musst auch hier nur mit Critical Sections arbeiten. Wenn es sehr viele Einträge werden können, macht auch eine TVirtualStringTree Sinn, da du dann nur die angezeigten Elemente aktualisierst, das macht es noch schneller.

Wenn das gut gemacht ist, hast du eine sich sehr performant anfühlende Anwendung, die die Möglichkeiten von Threads auch wirklich ausnutzt.

Hi,

vielen Dank für die Tipps ... da habe ich noch einiges vor mir ... ich werde das dann mal versuchen stück für stück umzusetzen ... ich bin mal gespannt wie es klappt

Grüße und Dank,
Andreas

ich bin grad mitten in der umsetzung und frage mich ... was ist wohl effektiver bei mehr als 25000 datensätzen

1. TStringList
2. TList
3. variables Array of records

beim adden muss ich immer einen string auf vorhandensein prüfen wegen der duplicates

Ich neige ja zum Array ... aber sicher bin ich mir nicht.

Das hört sich für einen typischen Anwendungsfall für TDictionary an (Unit System.Generics.Collections).
Da werden die Einträge gehasht und man kann mit Contains schnell herausfinden, ob ein Eintrag schon drin ist.

Ich sage vielen Dank .... wobei ich ehrlich gestehen muß das ich trotz meiner Arbeit mit Delphi seit Version 3.0 seit 1996 noch nie etwas davon gelesen habe

Das funktioniert ja auch erst mit Generics sinnvoll, deshalb gibt es das auch erst seit Delphi 2009 wie auch Generics.

Alternativ waere auch ein tclientdataset oder MemTable moeglich (bei der Menge). Da faellt dann das spaetere binden an die GUI etwas leichter.
Cherio Msch

Hi,

so ... ich habe das mal so versucht umzusetzen ... ein TDictionary für die eintragsverwaltung ... messages zum mainform/main thread / virtualtreeview ... den node habe ich um einen reinen pointer erweitert der direkt auf einen eintrag aus der liste zeigt ... kein syncen mehr sondern critical sections .... gibt es noch optimierungsbedarf oder habe ich etwas vergessen und nicht beachtet ? Wenn noch etwas wichtiges fehlen würde bin ich für richtungsweisende tipps immer offen ... ist ja mein erstes multithreading projekt

ich habe den source mal angehangen fürs form und für die unit mit dem threaded spider

Grüße,
Andreas