- 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.