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: