Klasse klasse mit mehreren Threads synchronisieren

[Gast]

Hiho.

Ich schreibe gerade mein ach so beliebtes LoggedOn2 um. Nun habe ich folgendes vor:

Schema der Klasse als Download fuer den Fall der Faelle (den sakura nun auch tatsaechlich schuf :mrgreen:)

• In blau und viereckig sind die Threads
• in blau und rund sind die Datenstrukturen
• hellgruen im Hintergrund und mit gruenem Rand ist die Abgrenzung dessen, was die Klasse leisten soll.
• Gelb, die GUI
• Rot, das Control (Treeview) identifiziert durch ein Handle!

Folgendermassen:

• Der MainThread soll den Dispatcher aufrufen und dann in die Nachrichtenschleife (der Anwendung) gehen.
• Der DispatcherThread startet zuerst den MachineScanThread und dann weitere (in der Unit oder Klasse festlegbare Anzahl) WorkerThreads.
• Sobald der MachineScanThread das erste Mal die Liste von Rechnern im LAN geholt hat, wird diese Liste an die Klasse rangehangen und der Index (Liste 1 oder 2) vermerkt.
• Danach werden die WorkerThreads einzeln (vom Dispatcher) beauftragt die einzelnen Rechner jeweils nach eingeloggten Usern zu scannen.
• Die WorkerThreads melden sich jeweils beim Dispatcher zurueck, sobald sie frei sind. Der Dispatcher verteilt dann weiter anliegende Arbeit.
  Ausserdem wird der Dispatcher bei Rueckmeldung veranlassen, dass der GuiUpdateThread ein Update des Treeview vornimmt.
• Findet der MachineScanThread nun beim Vergleich der aktuellen Liste mit seiner internen Liste von Rechnern einen neuen, oder vermisst er einen alten, so haengt er die neue Liste rein, updated den Index und gibt die alte Liste frei.
• Wird die Anwendung beendet, so wird der Dispatcher bei allen Threads die er startete veranlassen, dass sie sich beenden und die Daten freigeben. Dies wuerde im Destructor mit einer der Wait-Funktionen geloest.

Einzig ueber die Sache mit dem Index bin ich mir noch nicht im Klaren ... also bitte keine Kommentare dazu!

Also, meine Frage:
Wie koennte ich die einzelnen Teile sinnvoll und synchronisiert so verbinden, dass ich nicht den Vorteil der Multithreading verliere, dass mir aber andererseits nicht die Bytes hin und wieder nur so um die Ohren fliegen, weil's ne Exception gab?!

Bitte um qualifizierte Antworten. Grosse Teile sind bereits implementiert ... nur fliegt mir hin und wieder ne Exception um die Ohren ... offensichtlich wegen Sync-Problemen.

[edit=sakura]Bild wegen Größe entfernt - Download-Link ist ja vorhanden. Mfg, sakura[/edit]

[edit=Daniel B]Titel korrigiert. Mfg, Daniel B[/edit]

[sakura]

Ich denke mal, die Exception tritt im Moment auf, wenn die Listen up-to-date gebracht werden. Ich würde vorschlagen, dass Du an der Stelle entweder auf Interfaces wechselst - der Aufwand ist hier u.U. jedoch nicht gerechtfertig, oder Du lässt Deine Threads durch eine CriticalSection laufen, wenn Sie die Liste verändern wollen. Ersteres lässt alle Sorgen über, evtl. in der Zwischenzeit freigegeben Objekte verfliegen.

Vielleicht habe ich Dich aber auch nicht richtig verstanden :roll:

...:cat:...

[Gast]

Dieser Post wurde wegen grammatischer und ausdrücklicher :mrgreen: Stilblüten gelä ... ü ... öscht .. *verdammteenglischetastaturhat*

[sakura]

Ich meinte weniger die Downloadgröße - als die Bildgröße - die sprengt bei einigen Besuchern die Grenzen - ja, es gibt hier noch User mit 800-Pixel Auflösung :roll:

Was ist mit dem Rest :?: :mrgreen:

...:cat:...

[Gast]

Meist lande ich in LeaveCriticalSection irgendwo in der NTDLL oder der System32 ... wenn das Programm beendet wird und dann der Debugger zuckt.

Nachtrag:
Wozu gibt es Scrollbars? Wenn sich so jemand das auf seinem Homerechner anschaut, hat der das gleiche Prob :mrgreen:

[sakura]

Zitat:

Zitat von Assarbad

Lud ich diese Seite vor diesem Edit, war sie 125794 Bytes gross!

Davon sind jetzt ;-) 47.646 Bytes für die Seite, der Rest Grafiken, welche eh gecached sind. Damit mach das Bild fast 50% mehr Download aus. Aber wie gesagt, das war nicht der Grund ;-)

...:cat:...

[sakura]

Zitat:

Zitat von Assarbad

Meist lande ich in LeaveCriticalSection irgendwo in der NTDLL oder der System32 ... wenn das Programm beendet wird und dann der Debugger zuckt.

Hm, ich hatte bis jetzt keine Probleme, aber wozu gibt es Mutexes und andere Methoden um uns die Synchronisation schwer zu machen :mrgreen:

...:cat:...

[Gast]

LOL. Problem bei Mutexes, die sind leider echte und mit Namen bestueckte Kernelobjekte. Deshalb kann ich sie nicht gebrauchen. Denk mal an, was passiert, wenn ich mehrere Instanzen der Anwendung starte ;)

IMHO Critical Sections oder die InterLocked-Funcs ... was anderes kommt wahrscheinlich nicht wirklich in Frage. Noch ander Ideen?
Haste vielleicht mal selbst nen eigenen Sync-Mechanismus gebastelt?

[sakura]

Zitat:

Zitat von Assarbad

Haste vielleicht mal selbst nen eigenen Sync-Mechanismus gebastelt?

:lol: Ich bin gerade an einer Idee dran, die zwar auch auf dem MS-Prinzip basiert, allerdings auch auf der WinAPI Idee basiert.

Wenn Du trotzdem Mutexes nutzen willst, kannst Du an den Namen die Instance-ID des Programmes ranhängen und schon ist das Problem von MaxInt laufenden Instanzen gelöst ;-)

...:cat:...

[Gast]

Hast du jemals deine Instanzenhandles ausgewertet? Die sind alle die Lade-Adresse des Hauptmodules im eigenen Speicherbereich. Meist $400000 :D (seit Win32 erstmals rauskam ist dies so)

Wenn dann muesste es schon die Thread-ID oder so sein. Aber Mutexe sind ja grade deshalb langsam, weil es Kernelobjekte sind. Es muss der Thread ja in den Kernel-Mode jumpen und wieder zurueck. Das kostet mindestens 800 Zyklen.

Nachtrag:
Rueck mal ein paar konzeptionelle Details zu deinem Ansatz raus :mrgreen:

[sakura]

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

...:cat:...

[negaH]

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

[Gast]

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:

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.