Threadsicherer Nachrichten Queue mit Zugriff auf Control

[Schorsch]

Hallo,

ich hab einen OPC-Client (http://de.wikipedia.org/wiki/OLE_for_Process_Control) geschrieben der mit mehreren Threads arbeitet. Jeder dieser Threads erzeugt diverse Meldungen die in eine Logfile und in ein Grid geschrieben werden. Von der Software laufen 49 Instanzen auf diversen Servern ohne Probleme. Seit kurzem hab ich einen Kunden bei dem das Teil in unregelmäßigen Abständen knallt.

Ich habe nun den Verdacht die Appl. beim schreiben in das Grid auf die Schnauze fällt.

Ich will mir nun eine art Nachrichten-Queue erstellen der alle Meldungen erfasst, und dann in dem Logfile und dem Grid ablegt. Das ganze soll threadsicher sein. Hat jemand einen Tipp für mich bezüglich umsetzung?

Für den Queue sollte eine verkettete Liste reichen, nur wie soll ich die Threadsicherheit hinbekommen? Soll ich den wechselseitigen Aussschluss über einen Mutex, Semaphore oder Critical Section umsetzen? Ich muss Deadlooks, Abstürze usw. auf jeden Fall verhindern.

Die Umsetzung erfolgt via C++/MFC. Der Client bekommt ca. 2000 Messwerte/Sekunde soll Monate ohne Neustart durchlaufen.


Gruß

Schorsch

[eViL_oNe]

hört sich für mich eher nach "broken by design" an, aber vllt verstehe ich das auch verkehrt. Im Prinzip müsste das Model (in deinem Fall die Datenlieferanten) ein notify an die View (Grid bzw LogFile) absetzen, und sofern die Komponenten dazu bereit sind, stellen sie die neuen Daten dar (also etwa neue Zeile im Grid oder LogFile).

Für etwas genauere Infos wäre es hilfreich, wenn der Datenfluss und der grundsätzliche Ablauf sowie die Interaktionen der beteiligten Komponenten hier beschrieben sind.

Ob eine Message-Queue das richtige Mittel zur Wahl ist, bezweifle ich stark, so etwas gehört eher in die Kategorie "GUI-Programmierung in der Steinzeit" -- aber vllt verstehe ich ja die Problemstellung falsch ;)

[Schorsch]

Das Programm zu beschreiben ist recht schwer. Als ich das Projekt übernommen habe, hab ich Wochen benötigt es zu verstehen.....:(

Ich hab vor 3 Tagen mit einem Mutex experimentiert....die neue Version ist bei einem Kunden zum test online und läuft jetzt auch seit 3 Tagen ohne Probleme........
Am Montag bekommt der "Problemkunde" die Version....wenns dann immer noch knallt melde ich mich nochmal und beschreibe das Programm im Detail.

Gruß

Schorsch

[eViL_oNe]

noch etwas:

um eine Queue thread safe zu machen gehört nicht viel dazu. Grundsätzlich hat eine Queue ähnlich wie ein Stack nur zwei Operationen:

Push (stellt ein neues Element am Anfang der Schlange bereit)
Pop (holt das Element vom Ende der Schlange und entfernt es)

Evtl. gibt es noch eine dritte Operation, die ein Element vom Ende der Schlange holt, es allerdings nicht entfernt.

Diese 2-3 Operationen gilt es als kritische Pfade zu definieren. Dies kann man mit einem Mutex, einer Semaphore oder einem vergleichbaren Mechanismus lösen. Sobald eine der Operationen betreten wird, darf keine andere Operation mehr betreten werden, bis die Operation wieder verlassen wird. Sofern wir davon ausgehen können, dass alle Operationen korrekt terminieren und auch voneinander unabhängig sind, sollte es auch kein Deadlock geben.

Dennoch bezweifle ich, dass eine Queue hier das richtige Mittel ist. Grundsätzlich sollte es mit MVC viel einfacher zu lösen sein, notfalls unter Zuhilfenahme des Command-Patterns.