Asynchrone Sachen mit Bordmitteln sicher beenden.

Der Aufbau, das Vorhandensein, die Verschaltung und die Anzahl der Objekte ist vom Benutzer abhängig. Ich hätte dann die Wahl zwischen einem Thread der irgendwann umfällt und sich selbst blockiert oder einem Thread pro asynchronen Objekt (und ständigen Thread-wechseln).
So habe ich den Vorteil, dass die Events nach Freiheit verteilt werden und ein Thread sich direkt neue Arbeit besorgen kann, wenn er mit der letzten fertig ist, ohne einen weiteren Threadwechsel durchführen zu müssen. Ich meine, diese IO-Completion-Port-Sache skaliert extrem gut, aber ich bin auch nicht der Profi, der auf dieser Meinung beharren würde.

PS: Ich lese noch (und werde morgen frühe weiter) deinen Code. Ich habe noch das Problem, dass es bei mir dauert, bis ich beurteilen kann, ob ein sich synchronisierender Code so korrekt ist (Mir bleibt im Moment nicht mehr, als die Fälle durchzuspielen, weil ich nicht auf Muster zurückgreifen kann...).

Okay, alles klar, morgens ist immer besser als spät in der Nacht.
Eine Frage: Warum atomic_bool anstatt eines locks im Destruktor? Ich stelle mir das gerade so vor, dass bei jedem read in der Threadfunktion eine "atomic read" stattfinden muss, wieviel auch immer der kostet oder wie das in der CPU umgesetzt ist, obwohl sowieso schon ein Lock auf die Ressource gehalten wird.

Viele Grüße und Danke ~~für das Mitmachen~~ dafür, dass Du Dir für mich die Zeit nimmst!
Deci

cooky451

atomic Variablen können mitunter deutlich effizienter sein als locks. In jedem Fall sind sie "simpler" insofern, warum sollte man sie nicht benutzen?
Completion Ports sind sicher effizient, auch wenn ich noch nie gesehen habe, dass jemand sie für Interval-Timeouts genutzt hat. Mein Anliegen ist halt eher, dass ich mir nicht so sicher bin, ob sich diese Kopplung (diese Timeout Klasse ist ja jetzt nur in dieser Konfiguration mit asio benutzbar) wirklich lohnt, wenn man es auch mit Boardmitteln machen könnte.
Aber bitte, wenn hier ein Timeout/User o.Ä. erstellt wird, nicht die Lösung von oben benutzen! Ein Thread/User skaliert leider nur bis etwa 1000 Nutzern, u.U. noch schlechter. Aber dafür müsste ich halt noch ein paar mehr Dinge wissen: Wie genau muss das Timeout sein? (Die Zeit, die handler() benötigt, wird hier ja nicht mit einbezogen.) Haben alle Handler bei dir das gleiche Interval? Könnte man also eine Klasse nehmen die mehrere Handler, aber nur ein Interval hält?

volkard

cooky451 schrieb:

Ein Thread/User skaliert leider nur bis etwa 1000 Nutzern, u.U. noch schlechter.

Stimmt doch gar nicht.

Hallo cooky,
nun ich habe mich vielleicht etwas unglücklich ausgedrückt. Ich bin überzeugt davon, dass du mit den Kosten von atomic vs. mutex Recht hast. Ich meine viel eher, dass man diese atomic-Kosten bei Deinem Ansatz jeden Timer-Zyklus hat, vs. einmal die Mutex-Kosten in der stop-Methode.
Ich benutze die completion-ports auch hauptsächlich deshalb, weil ich sie schon für das asynchrone I/O benutze, also Dateien, serielle Schnitstellen und Netzwerkverkehr. Da habe ich die Timer einfach gleich mit einbezogen. Bei endlos-Lese-Sachen habe ich genau dasselbe Problem wie im OP beschrieben, nur ließ sich der Timer-Code einfacher als Beispiel hernehmen, bei dem anderen I/O hätte ich erst zusammenstauchen müssen!

Bis denne,
Deci

@ Volkard,
kannst du darauf etwas näher eingehen?
Ich glaube, die Diskussion kränkelt gerade daran, dass ich weder die 1-Thead/Asynchroner Komminikation-Strategie noch die Completion-Port-Strategie bis zum Kollaps ausprobiert habe, um Vergleiche zu führen zu können und Cooky keine Erfahrungswerte mit den Completion-Ports gesammelt hat.
Meine Wahl fiel auf sie, da sie mir einfach als "passend" einleuchteten, als ich mir über die Vorgehensweise Gedanken gemacht habe. Es funktioniert auch alles wunderbar, daher müsste ich mir erstmal Gründe erarbeiten, warum ich einen anderen Weg einschlagen sollte. Das ist schließlich immer mit Arbeit verbunden, später natürlich mit mehr als früher, daher bin ich auch sehr stark interessiert an einer vernünftigen Abwägung.

Viele Grüße,
Deci

cooky451

Du hast vergessen etwas zu beantworten:

cooky451 schrieb:

Aber dafür müsste ich halt noch ein paar mehr Dinge wissen: Wie genau muss das Timeout sein? (Die Zeit, die handler() benötigt, wird hier ja nicht mit einbezogen.) Haben alle Handler bei dir das gleiche Interval? Könnte man also eine Klasse nehmen die mehrere Handler, aber nur ein Interval hält?

Also ich möchte die durchaus bis runter zu den ~15ms verwenden können (aber mindestens irgendwas bei den 60ms), die Windows nunmal maximal bietet, bei Linux erreicht man so wohl 10ms? Keine Ahnung. Und ja, es kommen unterschiedliche Intervallzeiten zum Zuge. Und klar wackelt dann die ganze Zeit auch noch in der Phase oder wie man das ausdrücken soll ("Jitter"?). Was ich auf dem Bildschirm sehe, macht auf mich aber einen zufriedenstellenden Eindruck, also ist das Timing, so wie es gerade läuft, "gut genug".
Im GUI-Thread lege ich alle getimeten Animationen mit gleichem Intervall, und das sind wohl im Moment wohl alle, einfach adaptiv auf einen Timer zusammen (Das ist auch nötig, weil sonst längere Zeichenoperationen die restliche Animationen verdrängen). Da das beim asynchronen Prozess aber nicht so garantiert (weil Laufzeitkonfigurationsabhängig) ist, habe ich mir noch keine Mühe gemacht, asynchrone Timer "adaptiv" zusammenzulegen.

Wirkliche Echtzeit-Anforderungen habe ich aber nicht, nur so Pi mal Daumen so genau wie möglich.

Edit: Zweiter Grund warum ich die Timer nicht zusammengelegt habe: Das kann man auch in der Konfiguration so zusammenclicken, wenn man es denn will, spart erstmal Arbeit ;).

Nun gut,
ich habe etwas rumrecherchiert und es scheint so, dass die 1 Thread/Sache-Sache doch das Optimum darstellen könnte. Ich habe aber noch keine weitergehenden Vergleiche gesehen, die das im Vergleich mit den Completion Ports setzen. Auf jeden Fall behalte ich das einmal im Hinterkopf.

Gibt es eigentlich unter Windows noch irgendeine Option, die Timinggeschichte über etwas anderes als die herkömmlichen Timer zu regeln? Wie machen das denn Multimedia-Anwendungen (Media-Player, VLC, name it) Wohl eher so selbst steuerbar nicht, weil die mit dem Scheduler-Intervall zusammenhängen, oder?
Ich hatte in dem Zusammenhang auch mal über RTX-Extensions gelesen, bei denen man einzelne Cores komplett für Echtzeit-Sachen übernehmen kann, wenn das keine Knete kosten würde, wäre das echt eine tolle Geschichte Ansonsten bleibt einem ja wahrscheinlich "nur" irgendeine angepasste Version von Linux zu verwenden, und ich bin kein Linux-Typ
Für meine derzeitige Arbeit ist das nicht wichtig (sprich total unwichtig), aber ich träume noch davon, Echtzeitmodellsimulation für meine Roboterregelung umzusetzen, da wäre sowas echt gut. Wobei man sich natürlich auch mit einem Puffer und etwas Latenz behelfen kann. Aber der "Mikrocontroller"-Ansatz ist halt echt simpel.

volkard

Decimad schrieb:

@ Volkard,
kannst du darauf etwas näher eingehen?

Die Rechner sind vieeel schneller als ihr Ruf.
Ich lasse gerade einen vecor sortieren, der 80G groß ist bei nur 16G Ram. Na, und? Das BS läuft auf einem USB-Stick, 120G SSD und 1800G Platte darf er zum Swappen benutzen.

Wenn er eine Million Threads pro Sekunde erzeugen kann, ist das nicht ausreichend? Und wenn er bei 100000 gleichzeitig laufenden Threads ein wenig in die Knie geht, kauft man sich eben was cooles. Zweiten Rechner oder sowas.

Allerdings würde ich am Speicherverbrauch sehr knauserig sein. Zum Beispiel für einfache Webserverdinge jedem Thread nur 64k Stack geben, wo er auch noch seinen Freispeicher reinlegen soll.

Bevor ich Texten von vor 10 Jahren glauben würde (die übrigens ihrerseits älteres Wissen replizierten), würde ich ein Weilchen selber messen. Mir fehlen immer die Begründungen bei den 1:1-Ablehnern. Wo hakt es? Sind die Mutexe bei so vielen Anhängern lahm? Geht der Speicher aus? Wird der Scheduler lahm?

Wobei ich aber auch davon ausgehe, mir im Zweifelsfall das Betriebssystem aussuchen zu können. Vielleicht wird bei Windows irgendein nutzloser Sicherheitsdienst überlastet, vielleicht wird bei Linux das Speicher-Allokieren lahm, vielleicht sollte Dragonfly-BSD benutzt werden.

volkard

Decimad schrieb:

Gibt es eigentlich unter Windows noch irgendeine Option, die Timinggeschichte über etwas anderes als die herkömmlichen Timer zu regeln? Wie machen das denn Multimedia-Anwendungen (Media-Player, VLC, name it)

Du wirst es nicht glauben, extra dafür hat Windows Multimedia-Timer.

Die Waitable Timers http://msdn.microsoft.com/en-us/library/windows/desktop/ms686289(v=vs.85).aspx haben aber auch eine ganz hübsche Auflösung. Ich habe aber noch nicht gemessen, wie zweigerecht die Threads geweckt werden.

Whoah, Danke, die werde ich morgen mal im 1 Thread/Timer-Modus ausprobieren!
Das gute ist, dass die einzelnen Entitäten sowieso Threadsafe sein müssen, daher ist es rille, wie ich die Aufteilung der Events veranstalte.
Leider bin ich gerade erstmal an einer anderen Baustelle... Die Arbeit will nicht nachlassen...