targetNode : bis einschießlich diese Node-ID soll mindestens behandelt werden
- - +so einen Job auf den Level nach dem letzten Level setzen
- - ++ das Grooming-Token wird erst im WORKSTART gedroppt. Soweit kommen wir hier gar nicht, weil das Gate früher steht +
+ + ++ arbeitet nur ein Thread exclusiv +
+ + ++ dieser Fall: ja das ist sinnvoll +
+ + ++ habe ja schon mehrfach beobachtet, daß Cache-Effekte +100µs bewirken können. Insofern macht es absolut keinen Sinn, mehr als einen Thread in diese Zone reinzulassen, mit intensiver Queue-Interaktion +
+ + ++ 80µs für die reine Ausführung, wenn danach das Grooming-Token nicht wieder elangt werden kann (denn das dauert 20µs) +
+ + ++ ...das ist dann die Karenz-Zeit, nach der ein anderer Thread zum Zuge kommen könnte (der braucht aber auch noch mal 20µs um das Token zu erlangen +
+ + ++ ...das interpoliere ich aus mehreren Abläufen, wo sich jeweils eine Verzögerung in dem vorher festen poll-Zyklus zeigt, und zwar genau, wenn ein bisher erfolgloser Thread zum Zuge kommt (also an dem Punkt das Grooming-Token erlangt haben muß) +
+ + ++ also reinkommen, am Grooming-Token scheitern, rausfallen wieder reinkommen +
+ + ++ für den Zeithorizont < 100µs ist es sinnlos, nach Parallelisierung zu streben +
+ + ++ unklar bleibt, ob mehr als drei contendende Threads Schaden anrichten können +
+ + +danach / sonst : läuft verdächtig gut
- - ++ Genau betrachtet: diese Aussage stimmt nur in einem allgemeinen »work-horizon« von <20ms. Die Fokussierung ist nicht dynamisch, sondern mit einem Sprung, nämlich an der 5ms-Grenze +
+ + ++ Theorie-2 deckt sich mit emprischen Beobachtungen +
+ + ++ Fazit: es lief nur ordentlich, +
++ der Fall ist aber speziell und +
++ von unklarer Relevanz. +
+ + ++ kurze Lücken im Schedule + freie Kapazität ⟹ Ablaufsteuerung funktioniert sehr gut +
+ + ++ ein Beispiel: Dump-02 +
+ + ++ Abarbeiten eines Backlog muß fokussiert untersucht werden +
+ + ++ sofern Contention auftritt ⟹ tendentiell problematisch +
+ + ++ dort als Dump-03 +
+ + ++ ...und zwar von 5000µs ... 5982 +
+ + ++ und zwar anscheinend der Vorlauf, bis die Meldung vom Job-Funktor selber erscheint. +
++ Ein Beispiel: Dauer 400µs, Meldung nach > 300µs +
+ ++ nun läuft es wunderbar glatt +
+ + ++ denn durch die genaue Schedule-Berechnung und den präzisen pre-Roll ist nun bereits der erste Job ahead of schedule. +
++ ...das dreht sich dann typischerweise kurz (1.Tick, erste Kaskade von Jobs), aber dadurch entsteht höchstens ein Lag von 500µs, den ein einziger Worker locker wieder aufholt, zumal der konkrete Test-Graph hier am Anfang auch noch nicht die volle Breite hat. +
+ + ++ dokumentiert als Dump-01 +
+ + ++ ist auch explizit so gewünscht +
+ + ++ wenn er zur Berechnung „weg“ ist, und währenddessen taucht ein anderer Worker auf, dann schnappt sich letzterer das tend-next, und der aktuelle Thread wird erst mal weggeschickt +
+ + ++ ...diese beinhalten formal sogar zweimal einen postChain (das 2.mal wäre eigentlich stets redundant, ist aber formal sauberer). +
+ + ++ ...selbst wenn es dringendere Tasks in der Queue gäbe... +
+ + ++ das mag ärgerlich sein, dient aber einem »guten Zweck« +
++ Es ist eine der großen Errungenschaften, daß hier nun das Thema »Thread-Handling« in ein wirklich portables Framework gepackt wurde. Also mehr als „es ist POSIX“ !!! +
+ + +std::stringstream ss;
+ss << std::this_thread::get_id();
+int id = std::stoi(ss.str());std::hash<std::thread::id>{}(std::this_thread::get_id())std::thread::id threadId = std::this_thread::get_id();
+unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<void*>(&threadId));