ich schreibe ein Programm, mit dem verschiedene Sensoren kontinuierlich vermessen werden sollen.

Ich möchte dazu einen Scheduler schreiben, der sog. "Kanäle" verwaltet (als Ptr auf Instanzen einer Kanal-Basisklasse). Ein Kanal kann bspw. dafür zuständig sein einen Sensor zu vermessen, es gibt aber auch Kanäle die Messwerte anderer Kanäle abfragen und aus diesen Werten einen Wert berechnen.

Die Kanäle werden vor dem Programmstart anhand einer Konfigurationsdatei definiert und vom Programm eingelesen. Bei der Definition gibt es auch eine Angabe, in welchen Zeitintervallen der Kanal gemessen werden soll.

Jetzt stellt sich die Frage wie ich den Scheduler am besten schreibe. Ich habe mir das so vorgestellt, dass der Scheduler über ein Array/ einer Liste auf die Kanäle zugreift. Wenn ein Kanal vermessen wird (d.h. der Scheduler ruft den Kanal auf), macht er die Messung und berechnet dann den nächsten Zeitpunkt, zu dem er vermessen werden soll, mit "NextMeasTime = aktuelle Zeit + Zeitintervall aus KonfigDatei" (ich programmiere unter Linux und meine mit Zeitpunkten hier immer Unix-Timestamps, evtl auch mit Millisekunden).

Wenn ein Kanal vermessen wurde (und dieser Kanal hat evtl wiederum andere Kanäle vermessen, die ihre NextMeasTime dann auch neu berechnet haben), muss der Scheduler dann irgendwie nachschauen welches der nächste zu vermessende Kanal ist und wann er vermessen werden muss. Dann kann sich das Programm mit einem usleep(nächster Messzeitpunkt - aktuelle Zeit) schafen legen und beim Aufwachen den nächsten Kanal vermessen. Zeitkritisch an der Sache ist evtl die Dauer der Messungen (Kommunikation, warten aufs Ergebnis), v.a. wenn es viele Kanäle gibt. Es könnten schon mal ein paar hundert Kanäle werden.

Ich suche jetzt die beste Möglichkeit, die Kanäle im Scheduler zu verwalten.

Erste Möglichkeit wäre ein ganz normales Array mit Basisklassen-Pointern: Die Kanäle werden ja nur einmal eingelesen, muss also eh nicht dynamisch erweiterbar sein. Nachteil: Der Scheduler muss immer den ganzen Array durchgehen und schauen welches der "kleinste Timestamp" ist.

Ich habe mir auch die Container aus der STL angesehen:

- vector, deque, queue und stack kann ich ausschließen, genauso wie Set und Multiset
- STL priority_queue: Der Name hört sich gut an, aber das ist - so wie ich's verstehe - eine ungeordnete vector-Liste und dann eher ungeeignet.
- Die Map ist nix weil der NextMeasTime-Timestamp als Key fungieren würde, und ein NextMeasTime-Timestamp kann ja mehrmals vorkommen.

Bleiben noch list und map:
- Ob mir die Liste viel Vorteile bringt bezweifle ich, die Funktionen die sie kann brauch ich eigentlich nicht.
- Die Multimap hört sich gut an, da - wie ich gelesen habe - die Speicherung der Elemente in einem balancierten B-Baum geschieht. Aber ist die Multimap in meinem Fall effizient? Damit der Scheduler den nächsten Kanal schnell findet, müsste ein Kanal, nachdem er gemessen wurde und seinen NextMeasTime neu berechnet hat, im Baum jedesmal "gelöscht" und neu einsortiert werden. Geht das mit der Multimap? Wenn ja wäre sie vielleicht die bessere Alternative zum Array.

Mir fällt noch eine Frage ein: Das Programm lauscht auf einem TCP/IP-Socket und muss dann ggf. Daten verschicken. Wie kann ich verhindern, dass ich mit dem usleep() einen
Verbindungsaufbau verschlafe? Ich hoffe das torpediert meinen geplanten Scheduler nicht...

So, das war jetzt viel Text und ich hoffe dass ich mit der Frage nach dem passenden Algorithmus hier im richtigen Forum bin...

Stephan

Mit push fügst du deine neuen "Kanal-Zeit-Messungs-Objekte" ein.

Mit top guckst du wann der nächste Kanal gemessen werden soll und schläfst ggf. mit usleep bis der Zeitpunkt erreicht ist.

Mit pop entfernst du das Objekt, misst den Kanal, berechnest den nächsten Messzeitpunkt und fügst ihn mit push wieder in die queue ein.

Also ich finde das ist relativ überschaubar.

danke für den Hinweis, auf Deinen Rat hin ich hab mir die priority_queue jetzt nochmal durchgelesen.

Auf www.cppreference.com habe ich gesehen dass die Funktionen pop() und push() in logarithmischer Zeit ablaufen (was mich echt verwundert wenn das Ganze nicht in irgendeiner Baumstruktur verwaltet wird).

Als Speicherklasse kann man vector und deque verwenden. Wenn bei einer deque Elemente überall eingefügt werden können, heißt das dann für den vector dass Elemente nicht am Anfang einsortiert werden könnten?? Was bedeutet das für eine Priority Queue?

Für meine Kanalklassen müsste ich dann noch - damit der Kanal mit dem kleinsten Timestamp höchste Prio hat - den greater-Operator überladen.

Allerdings sehe ich grade, dass ich mit fast allen STL-Containerklassen noch ein anderes Problem habe: Beim Einfügen in einen Container übergebe ich ja Objekte und keine Pointer, von den Objekten wird dann eine Kopie angelegt. Damit hab ich aber das Problem dass ich auf einen Kanal nicht mehr anders zugreifen kann als über die Prioritätenliste. Das wäre aber nötig um beim Messen eines Kanals evtl. andere Kanäle, die dieser als Membervariable (Ptr auf Kanalobjekt) gespeichert hat, nachzumessen.

Übergebe ich beim Einfügen Pointer, dann funktionieren die Vergleichsoperationen nicht mehr. Außerdem wird von Pointern in STL-Containern abgeraten.

Damit könnte ich die Priority Queue nicht verwenden. Die multimap hingegen wäre noch nicht ganz aus dem Rennen da es einen wahlfreien Zugriff über einen Key gibt. Dann bräuchten die Kanäle, die andere Kanäle zum Nachmessen aufrufen, aber selbst Zugriff auf die multimap.
Oder ich übergebe der Multimap doch Pointer auf die Kanal-Objekte.

Das ist irgendwie komplizierter als ich dachte...

damit der Kanal mit dem kleinsten Timestamp höchste Prio hat - den greater-Operator überladen.

Wasn dein Timestamp ? wenn das nen nativer Typ, also sowas wie unsigned long long, oder unsigned __int64 ist, sind die Lesser Funktionen schon bereits vorhanden. DIe koenntest nutzen.

2.

Beim Einfügen in einen Container übergebe ich ja Objekte und keine Pointer, von den Objekten wird dann eine Kopie angelegt.

Das ist natuerlich ned immer gewollt. Deshalb kannst du auch ohne Probleme Zeiger in Container packen. Der Container sollte dann natuerlich vom Typ "Zeiger auf ..." sein. Das die zeiger immer gueltig, also die auf die verwiesenen Elemente immer noch existieren, dafuer bist sicher selber zustaendig

3. Uber was fuer Zeiten reden wir hier, wie genau muss der scheduler sein, was fuer Zeiten fuers schlafenlegen und fuer Zeiten fuers messen werden erwartet. Nix ist schlimmer als wie nen scheduler der so mit sich selbst beschaeftigt ist, das er die Events die er ausloesen soll, verpennt ^^ Irgendwie klingt das ziemlich kompliziert und laufzeitkritisch was du da vorhasst, vielleicht gibts ne lauftechnisch einfachere version ....

Ciao ...

Auf www.cppreference.com habe ich gesehen dass die Funktionen pop() und push() in logarithmischer Zeit ablaufen (was mich echt verwundert wenn das Ganze nicht in irgendeiner Baumstruktur verwaltet wird).

http://www.cplusplus.com/ schrieb:

Support for random access iterators is required to keep a heap structure internally at all times.

Mit heap ist hier bestimmt der Baum gemeint (nicht der Speicherbereich). Kann mich auch irren, habs nur überflogen.

Radix schrieb:

Allerdings sehe ich grade, dass ich mit fast allen STL-Containerklassen noch ein anderes Problem habe: Beim Einfügen in einen Container übergebe ich ja Objekte und keine Pointer, von den Objekten wird dann eine Kopie angelegt. Damit hab ich aber das Problem dass ich auf einen Kanal nicht mehr anders zugreifen kann als über die Prioritätenliste. Das wäre aber nötig um beim Messen eines Kanals evtl. andere Kanäle, die dieser als Membervariable (Ptr auf Kanalobjekt) gespeichert hat, nachzumessen.

Übergebe ich beim Einfügen Pointer, dann funktionieren die Vergleichsoperationen nicht mehr. Außerdem wird von Pointern in STL-Containern abgeraten.

Zum Speichern von Zeigern in STL-Containerklassen wird immerwieder boost::shared_ptr empfohlen (shared_ptr ist sozusagen eine Containerklasse für Zeiger, die die Zeiger automatisch löscht, wenn sie nicht mehr benutzt werden). Ich weis aber nicht ob beim Verleich von shared_ptr-Objekten der Vergleichsoperator des Objektes genutzt wird, auf den shared_ptr zeigt.

Auf welcher Plattform soll dein Programm laufen? Windows, Linux oder einem µc?

RHBaum schrieb:

3. Uber was fuer Zeiten reden wir hier, wie genau muss der scheduler sein, was fuer Zeiten fuers schlafenlegen und fuer Zeiten fuers messen werden erwartet. Nix ist schlimmer als wie nen scheduler der so mit sich selbst beschaeftigt ist, das er die Events die er ausloesen soll, verpennt ^^ Irgendwie klingt das ziemlich kompliziert und laufzeitkritisch was du da vorhasst, vielleicht gibts ne lauftechnisch einfachere version ....

seh ich auch so ...

Wasn dein Timestamp ? wenn das nen nativer Typ, also sowas wie unsigned long long, oder unsigned __int64 ist, sind die Lesser Funktionen schon bereits vorhanden. DIe koenntest nutzen.

Mein Timestamp nach Möglichkeit "unsigned int" sein (ich würde einfach die UNIX-Time verwenden, aber gaaanz evtl muss ich noch die msec mit reinbringen). Der Datentyp der verglichen werden muss ist ja der den ich dem Container übergebe, also nicht der Timestamp selbst (davon weiß der Container nix), sondern die Kanal-Basisklasse. Den Operator "<" für die Klasse müsste ich dann eben so überladen dass er die Membervariablen vergleicht (was ja kein Problem ist).

RHBaum schrieb:

3. Uber was fuer Zeiten reden wir hier, wie genau muss der scheduler sein, was fuer Zeiten fuers schlafenlegen und fuer Zeiten fuers messen werden erwartet. Nix ist schlimmer als wie nen scheduler der so mit sich selbst beschaeftigt ist, das er die Events die er ausloesen soll, verpennt ^^ Irgendwie klingt das ziemlich kompliziert und laufzeitkritisch was du da vorhasst, vielleicht gibts ne lauftechnisch einfachere version ....

Tjaaa...ich _glaube_ dass ich einzelne Sensoren nicht schneller vermessen muss als im niedrigen Sekundentakt, manche auch wesentlicher seltener. Das ist aber veränderlich und von den äußeren Einflüssen abhängig.

Chris++ schrieb:

Auf welcher Plattform soll dein Programm laufen? Windows, Linux oder einem µc?

Läuft unter OpenSUSE-Linux ohne X-Server, die Rechner werden wohl preiswerte Desktop-Rechner sein.

Chris++ schrieb:

Zum Speichern von Zeigern in STL-Containerklassen wird immerwieder boost::shared_ptr empfohlen

Das werd ich mir mal ansehen, aber wenn der Vergleichsoperator die Adressen vergleicht dann ist's natürlich nix.

RHBaum schrieb:

Irgendwie klingt das ziemlich kompliziert und laufzeitkritisch was du da vorhasst, vielleicht gibts ne lauftechnisch einfachere version ....

Da bin ich für Vorschläge offen da mir selbst leider nix einfällt. Im Moment wäre der simple Array die einfachste Lösung.

Mich würde mal die Zeit interessieren, die so ein Scheduler durchschnittlich brauchen würde um bspw. den kleinsten Timestamp von 400 Kanälen zu finden. Vielleicht füll ich einfach mal einen Array mit einfachen Objekten, die Membervariablen mit Zufallszahlen besitzen, und messe die Zeit mit gettimeofday().

Chris++ schrieb:

Zum Speichern von Zeigern in STL-Containerklassen wird immerwieder boost::shared_ptr empfohlen

Das werd ich mir mal ansehen, aber wenn der Vergleichsoperator die Adressen vergleicht dann ist's natürlich nix.

Stimmt. Du kannst bei der priority_queue aber eine Compare-Klasse angeben. Du könntest dir eine eigene schreiben, die wiederum den operator < so überlädt, dass sie deine Objekte dereferenziert und eben die Timestamps vergleicht (und nicht die Adressen).

Radix schrieb:

Da bin ich für Vorschläge offen da mir selbst leider nix einfällt. Im Moment wäre der simple Array die einfachste Lösung.

Mich würde mal die Zeit interessieren, die so ein Scheduler durchschnittlich brauchen würde um bspw. den kleinsten Timestamp von 400 Kanälen zu finden. Vielleicht füll ich einfach mal einen Array mit einfachen Objekten, die Membervariablen mit Zufallszahlen besitzen, und messe die Zeit mit gettimeofday().

Bei nur 400 Kanälen funktioniert die Variante mit dem Array vieleicht. Ich würde es aber nicht so machen. Denn wenn du 400 Timestamps in deinem Array hast, dann musst du bei jedem Durchgang alle Elemente durchsuchen und dir das kleinste merken. Das heist, du verbrauchst immer 400 Such- und Vergleichoperationen. Wenn du später dann 1000 Elemente vergleichen musst, dann brauch dein Algorithmus aufeinmal 1,5 mal so lang wie vorher.

Besser ist es, deine Kanäle gleich sortiert in deine Datenstruktur einzufügen. Dann befindet sich am Anfang immer das kleinste Element. Wie auch immer... das Problem hierbei ist, das du bestimmt auch Elemente in der Mitte von deinem Array einfügen musst. Jetzt füge mal an Position 200 ein neues Element ein. Dann musst du alle andeen 200 weiter nach hinten kopieren... und das bei jeder Einfügeoperation (mal mehr mal weniger). Was du dann beim Suchen sparst verbrauchst du quasi wieder beim Einfügen.

Besser wäre hier also eine doppelt verkettete Liste (Bsp. std::list). In ihr kannst du bequem Elemente in die Mitte einfügen ohne alle anderen zu kopieren. Der Nachteil von der Liste ist, dass du nicht direkt auf ein beliebiges Element zugreifen kannst. Du musst dich vom ersten bis zu deinem Zielelement durchhangeln. Das ist aber nicht soo schlimm, da du beim sortierten Einfügen sowieso nach dem größten Element suchen musst. Im schlimmsten Fall verbrauchst du also 400 Suchoperationen. Im besten Fall nur eine (wenn dein Element schon das kleinste ist). Aber im Grunde ist das wieder nur eine priority_queue.... wo wir wieder beim Anfang wären

Ich würde aber zum Suchen eher eine Baumstruktur (z.B. std::multimap) verwenden. Die von der STL hat aber leider keine front() push_back() und pop_back() Funktionen. Wenn die priority_queue intern wirklich einen heap verwaltet (der ja ein Suchbaum ist), dann ist sie vieleicht nach genau das richtige für dich.

Auch wenn ein B-Baum die elegantere Lösung wäre (den ich mir ohne Balanciereung notfalls selber schreiben könnte) spricht bei solchen Zeiten imho nichts gegen eine Array.