monitor 1.9.0 - aber richtig :)

[Buebchen]

Hallo,

Wenn aber die Geschichte mit den *msg-Objekten realisiert wird - dann könnte doch einfach eine Datenstruktur (Array, verkettete Liste, ...) die *msg-Objekte pro Thread halten (hält der Thread selber oder soll das gebündelt vor der Übergabe an die Threads passieren?).

Im Moment sind es getrennte Listen (std::list) pro Thread. Geht auch soweit. Ich würde sie dann ggf. nur denmächst mal in eine Klasse einbetten, da ich immer auch über eine Semaphore sicherstellen muss, da immer nur ein Prozeß die Liste ändert. Nach meiner Meinung müssen die Objekte pro Thread in eine eigene (private) Queue. Sonst könnte ich erst das Element aus der zentralen Queue entfernen, wenn alle Threads es abgearbeitet habe (was dann synchronisiert werden müßte).

Änderung I:
..., können die auflaufenden Nachrichten aber auch queuen, falls bei den Modulen ein Problem auftritt - pro Modul wäre da eine Queue sinnvoll, damit bei fehlerhaftem Verhalten eines Moduls die anderen noch sauber weiterarbeiten können ...

Martin

So in der Art würde ich mir das auch vorstellen können. Dann sollten wir einen Dispatcher als Dreh- und Angelpunkt für die Nachrichten vorsehen. Dieser bedient dann bei ihm registrierte Module (Füllt deren privaten Queues - ggf aber nur bis zu einem Limit von vielleicht 100 Einträge). Ich wüßte im Moment nur nicht, warum ich für Display und Storage verschiedene Dispatcher brauche. Die Daten sind identisch - nur die spätere Verarbeitung nicht. Wenn jedes Modul - wie es schon beim SocketThread ist - seine eigene Queue könnte man die StorageModule genauso behandeln.