diff --git a/src/vault/gear/activity.hpp b/src/vault/gear/activity.hpp index f84e7fed9..66d04cef9 100644 --- a/src/vault/gear/activity.hpp +++ b/src/vault/gear/activity.hpp @@ -629,7 +629,12 @@ namespace gear { switch (verb_) { case NOTIFY: - return notifyTarget (now, executionCtx); + { + auto res = notifyTarget (now, executionCtx); + if (activity::PASS == res) + res=activity::SKIP; // prevent activation of NOTIFY.next + return res; + } case POST: case FEED: // signal just to proceed with next... return activity::PASS; diff --git a/tests/vault/gear/scheduler-activity-test.cpp b/tests/vault/gear/scheduler-activity-test.cpp index 41494a140..8184d4987 100644 --- a/tests/vault/gear/scheduler-activity-test.cpp +++ b/tests/vault/gear/scheduler-activity-test.cpp @@ -355,7 +355,6 @@ namespace test { * - verify the basic outfitting and sane connectivity * - verify values reported by the BlockFlow allocator * - ensure the defined Job can be properly invoked - * @todo WIP 8/23 ✔ define ✔ implement */ void termBuilder() @@ -403,7 +402,14 @@ namespace test { /** @test verify the ability to _dispatch and perform_ a chain of activities. * - use a directly wired, arbitrary chain * - dispatch will activate all Activities - * @todo WIP 8/23 🔁 define ⟶ implement + * - however, when the Gate is configured to be blocked + * (waiting on prerequisites), then the rest of the chain is not activated, + * only a re-check of the Gate is scheduled for later (1.011 -> 2.011) + * - the dispatch function also handles the notifications; + * when a notification towards the Gate is dispatched, the Gate is + * decremented and thereby opened; activation of the rest of the chain + * is then planned (but not executed synchronously in the same call) + * @todo WIP 8/23 ✔ define ✔ implement */ void dispatchChain() @@ -419,9 +425,31 @@ namespace test { // insert instrumentation to trace activation detector.watchGate (post.next, "Gate"); - CHECK (activity::PASS == ActivityLang::dispatchChain (post, tt, detector.executionCtx)); + CHECK (activity::PASS == ActivityLang::dispatchChain (post, tt, detector.executionCtx)); // start execution (case/seq == 0) + CHECK (detector.verifyInvocation("Gate") .arg("1.011 ⧐ Act(GATE") // ...first the Gate was activated + .beforeInvocation("after-Gate").arg("1.011 ⧐ Act(TICK") // ...then activation passed out of Gate... + .beforeInvocation("CTX-tick") .arg("1.011")); // ...and finally the TICK invoked the λ-tick - cout << detector.showLog()< Act(GATE") // ...notification dispatched towards the Gate + .beforeInvocation("CTX-post").seq(2).arg("1.011","after-Gate","≺test::CTX≻")); // ...this opened the Gate and posted/requested activation of the rest of the chain + CHECK (detector.ensureNoInvocation("after-Gate").seq(2) // verify that activation was not passed out directly + .afterInvocation("CTX-post").seq(2)); + CHECK (detector.ensureNoInvocation("CTX-tick").seq(2) // verify also the λ-tick was not invoked directly + .afterInvocation("CTX-post").seq(2)); } diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index d05e88c7a..998e1f53c 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -66047,9 +66047,7 @@ - - - +

Thema: Memory access order constraints @@ -66062,9 +66060,7 @@ - - - +

Grundidee: synchronizes-with-Beziehung herstellen auf Guard-Variable @@ -66078,9 +66074,7 @@ - - - +

...das meint zweierlei @@ -66098,9 +66092,7 @@ - - - +

essentiell ist, im Mutex-geschützten Bereich @@ -66120,9 +66112,7 @@ - - - +

warum? @@ -66151,9 +66141,7 @@ - - - +

es gilt schlichtweg als Architektur-Fehler, wenn hier eine Kollision geschiet. @@ -66171,9 +66159,7 @@ - - - +

...denn sonst könnte genau das gleiche Desaster passieren, @@ -66196,9 +66182,7 @@ - - - +

...d.h. das ganze Locking und die memory-order schützt uns hier überhaupt nicht! @@ -66217,9 +66201,7 @@ - - - +

unsere Architektur stellt aber sicher, @@ -66230,9 +66212,7 @@ - - - +

warum? @@ -66264,9 +66244,7 @@ - - - +

hier ist ein Segfault möglich @@ -66292,9 +66270,7 @@ - - - +

...denn wir sind auf x86_64 -- und diese Plattform ist per default fast überall sequentially coherent @@ -66349,9 +66325,7 @@ - - - +

...man könnte ihn aber genausogut auch machen. @@ -66378,9 +66352,7 @@ - - - +

hier notwendig, weil wir eine neue Factory-Funktion ablegen. @@ -66433,9 +66405,7 @@ - - - +

zwar wird beim Löschen des Mock @@ -66458,9 +66428,7 @@ - - - +

...und man stattdessen explizit eine gefährliche Funktion  aufrufen muß @@ -66565,9 +66533,7 @@ - - - +

...da es sich ja nur um die Factory handelt, @@ -66619,9 +66585,7 @@ - - - +

Konsequenz: das ist keine Library-Implementierung @@ -66724,9 +66688,7 @@ - - - +

die von der alten DependencyFactory abhängen @@ -66791,9 +66753,7 @@ - - - +

...wenn man nämlicht Lumiera's Lösung nicht genau kennt, @@ -66812,9 +66772,7 @@ - - - +

DependencyFactory ist viel besser geeignet @@ -66937,9 +66895,7 @@ - - - +

den habe ich nicht mehr über das Interface-System gemappt @@ -66947,9 +66903,7 @@ - - - +

weil mir das ganze C-gefrickel zu blöd geworden ist. @@ -66995,9 +66949,7 @@ - - - +

der Interface-Anbieter implementiert einen konkreten Proxy @@ -67094,9 +67046,7 @@ - - - +

Modus der Definition @@ -67126,9 +67076,7 @@ - - - +

...wir müssen immer, für jeden Proxy @@ -67179,9 +67127,7 @@ - - - +

brauchen eigenen Zugriffs-Mechanismus auf ein weiteres Handle-Objekt @@ -67224,9 +67170,7 @@ - - - +

...oder sogar den ctor, das ist egal -- @@ -67289,9 +67233,7 @@ - - - +

obwohl es das sollte. @@ -67323,9 +67265,7 @@ - - - +

sie ist zwar nicht schön -- aber was ist an einem Interface-Binding schon "schön"? @@ -67355,9 +67295,7 @@ - - - +

das ist ein konzeptionelles Problem. @@ -67473,9 +67411,7 @@ - - - +

...und lib::Depend so umarrangiert, @@ -67511,9 +67447,7 @@ - - - +

so wie das Advice-System geschrieben ist, @@ -67524,9 +67458,7 @@ - - - +

denn grundsätzlich ist das ganze Advice-System bewußt "billig" implementiert; @@ -67657,9 +67589,7 @@ - - - +

...weil Nobug-Init ON_BASIC_INIT braucht, @@ -67692,9 +67622,7 @@ - - - +

und heute würde ich den Code so nicht mehr schreiben @@ -67705,9 +67633,7 @@ - - - +

genauer: @@ -67766,9 +67692,7 @@ - - - +

...es ruft sich selbst rekursiv auf, via Depend<AdviceSystem> @@ -67779,9 +67703,7 @@ - - - +

...nämlich eine ganz spezielle, dedzierte Aufräum-Routine schreiben @@ -67852,9 +67774,7 @@ - - - +

das «Regel-System» @@ -67867,9 +67787,7 @@ - - - +

das «Advice-System» @@ -67880,9 +67798,7 @@ - - - +

auch in 2019... @@ -67900,9 +67816,7 @@ - - - +

ein Whiteboard-System @@ -67942,9 +67856,7 @@ - - - +

....denn es gibt die default-Lösung @@ -67967,9 +67879,7 @@ - - - +

im Sinne des Erfinders... @@ -68052,9 +67962,7 @@ - - - +

...und das kann ziemlich indirekt passieren. @@ -68070,9 +67978,7 @@ - - - +

C++ hällt die Erzeugungs/Zerstörungs-Reihenfolge exakt ein @@ -68082,9 +67988,7 @@ - - - +

d.h. wenn das local static später erzeugt wird, wird es vor  dem Hauptobjekt zerstört @@ -68103,9 +68007,7 @@ - - - +

Statische Initialisierung funktioniert präzise, korrekt und zuverlässig @@ -68116,9 +68018,7 @@ - - - +

Der Aufruf von Konstrukturen statischer Objekte konstituiert eine (dynamische) Reihenfolge. @@ -68195,9 +68095,7 @@ - - - +

Aufgabe: produce dummy content @@ -68275,9 +68173,7 @@ - - - +

...obwohl die betreffenden Assets in die Kategorie "Medien" fallen, @@ -68298,9 +68194,7 @@ - - - +

...nämlich genau nicht für alle Assets, @@ -77959,13 +77853,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + - - + + @@ -78066,8 +77960,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - + + @@ -78083,9 +77977,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - +

Verwaltung des GroomingToken @@ -78096,14 +77988,14 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + - - + + @@ -80007,16 +79899,19 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - + + - - + + + + + @@ -80024,6 +79919,32 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + + + + + + + + + + + + +

+ gesamte Kette ausführen per ActivityLang::dispatchChain() +

+ + + +