Mit geht es momentan um eine globale CS - da ist der Ansatz von Hagen super: http://www.delphipraxis.net/viewtopic.php?t=7357

......

Nutze InterlockedXXXX() funktionen und Zwischengespeicherte Ergebnissmengen. Der TreeView wiederum nutzt Polling um per InterlockedXX() Variablen die Zwischengespeicherten Mengen in seinen Context zu kopieren. Soweit in kurzform, ich glaube aber ich muß es klarer verdeutlichen.

Der TreeView zeigt einen bestimmten Status an. Dazu werden dahinterliedende Datenmengen benötigt. Der UpdaterThread hat ein eigenes vollständiges Duplikat dieser Daten, aktualisiert alle Änderungen und erzeugt die Daten die dann im TreeView angezeigt werden. Nun inkementiert er einen Zähler per InterlockedIncrement(FMustDisplay).

Der UpdaterThread aktualisiert die Daten wenn FMustUpdate = 0 ist und setzt diesen Wert auf 1 während er Updated. Ist er fertig mit dem Update dann erhöht er diesen Wert auf 2. Der MainThread.TTreeView pollt FMustDisplay und wenn der Wert 2 vorliegt beginnt er diese Daten einzuarbeiten. Er erhöht den Wert auf 3 und wenn er fertig ist setzt er ihn auf 0 zurück.

Da ein Zugriff auf einen an 4 Bytegrenzen ausgerichteten Integer als Atomarer Zugriff stattfindet, und atomare Operationen der CPU threadsafe sind, lässt sich das sogar ohne InterlockedXXX() Funktionen erledigen.

Solange FMustDisplay <= 2 ist kann der UpdaterThread erneut seine Daten ändern. Da der TreeView im Idle-Modus, also immer FMustDisplay pollt wenn keine Messages im Queue sind, wird es sogar möglich das der UpdaterThread mehrmals sehr schnell hintereinander die daten aktualisert. Der TreeView zeigt aber immer nur den letzten Zustand an, also leicht Zeitversetzt.

Gruß Hagen

Danke erstmal an sakura. Ich werde es aber erstmal noch nicht nehmen.
Ich bleibe mal bei den CS der API.

Also,

hab mir das jetzt mal so ausgedacht:

markieren

Code:

- Die Klasse hält (privat) die ID und das Handle zum DispatcherThread
- Dadurch kann mit PostThreadMessage() der Dispatcher kommandiert werden
- Der Disptacher kümmert sich intern um die Geschäfte mit allen anderen
  Threads, inklusive deren Steuerung, Beendigung etc pp.
- Der Dispatcher reicht einen Pointer zu der Liste mit den Rechnern an
  jeden Thread weiter, der was tun soll (GUI, MAC, Workers). So wissen
  diese ab dem Start, wo sie gucken können, wenn sie in der Liste stöbern
  müssen. Dieser Pointer muß von den Threads als Readonly behandelt werden.
- Update der Daten kommt sowieso nur von den Workers! Diese müssen ein
  Update anmelden, indem sie per PostMessage den Pointer zu den Daten für
  die eingeloggten User sowie den Index des Records zurückgeben.
- Der Dispatcher macht das Update, sobald keiner der Threads mehr gerade
  diesen Record liest! Will heißen, NUR der Dispatcher bestimmt, wann er
  die Records tauscht ... weshalb es NICHT ERLAUBT ist, daß ein anderer
  Thread (zB Hauptthread) die Adresse des Records zwischenspeichert!
- Der vorige Punkt sollte klarer werden, sobald man weiß, daß der GUI-
  Thread nur per PostThreadMessage() vom Dispatcher den Befehl für ein
  Update erhalten kann.
- Critical Sections werden gebraucht für:
  + Update der Liste mit den Rechnern im Netzwerk
  + Schreiben/Lesen der Daten welcher User wo eingeloggt ist.

Ich hoffe, daß ich dadurch, daß die Verwaltung der anderen Threads nur
noch dem Dispatcher obliegt, es schaffen kann die Konflikte auszuräumen.
Unter anderem sollte es dann möglich sein auf einige (vielleicht sogar
mehr als geplant) Critical Sections zu verzichten, da die Abarbeitung
ja allein durch die Benutzung von Message-Loops in den Threads einger-
maßen serialisiert worden sein sollte.