diff --git a/src/vault/gear/scheduler-commutator.hpp b/src/vault/gear/scheduler-commutator.hpp index 2c95bf8e4..0cf259965 100644 --- a/src/vault/gear/scheduler-commutator.hpp +++ b/src/vault/gear/scheduler-commutator.hpp @@ -198,9 +198,13 @@ namespace gear { layer1.feedPrioritisation(); while (layer1.isOutdated (now) and not layer1.isOutOfTime(now)) layer1.pullHead(); - if (layer1.isDue (now) and not layer1.isOutOfTime(now)) - return layer1.pullHead(); - } + if (layer1.isDue (now)) + { + if (layer1.isOutOfTime(now)) + UNIMPLEMENTED ("how to trigger a Scheduler-Emergency from here"); ///////////////////////TICKET #1362 : not clear where Scheduler-Emergency is to be handled and how it can be triggered. See Scheduler::triggerEmergency() + else + return layer1.pullHead(); + } } return ActivationEvent(); } diff --git a/src/vault/gear/scheduler.hpp b/src/vault/gear/scheduler.hpp index 8ae1930e2..2ed91070b 100644 --- a/src/vault/gear/scheduler.hpp +++ b/src/vault/gear/scheduler.hpp @@ -704,6 +704,12 @@ namespace gear { /** * Trip the emergency brake and unwind processing while retaining all state. + * @todo as of 4/2024 it is not clear what Scheduler-Emergency actually entails; + * thus it can not be determined at which level of the component the handler + * must reside, and how it can be reached. Notably there exists a situation + * in `SchedulerCommutatior::findWork()`, where emergency can happen, yet + * in its current configuration, the Layer-2 has no access to the top-level + * Scheduler component. /////////////////////////////////////////////////TICKET #1362 : where to handle Scheduler-Emergency */ inline void Scheduler::triggerEmergency() diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index ce4a773ba..0c859332b 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -83779,7 +83779,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + @@ -83802,15 +83802,20 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
einmal ist es der Scheduler selber, dessen Funktionalität abstrahiert als ExecutionCtx bereitzustellen ist
  • - die WorkForce hingegen ist konzeptionell selbständig, wird aber vom Scheduler übernommen und gezielt parametrisiert, einschließlich der Abstraktion doWork(), welche dann doch vom Scheduler selbst zustammengestellt wird + die WorkForce hingegen ist konzeptionell selbständig, wird aber vom Scheduler übernommen und gezielt parametrisiert, einschließlich der Abstraktion doWork(), welche dann doch vom Scheduler selbst zustammengestellt wird
  • - nochmal anders ist die Situation beim LoadController, der so etwas wie die Steuerzentrale darstellt: konzeptionell ist er total vom Scheduler abhängig, aber seine Implementierung ist entkoppelt,  wiewohl in beide Richtungen verdrahtet mit wechselseitiger Abhängigkeit. In diesem Fall muß also ein Abhängigkeitszyklus durchbrochen werden + nochmal anders ist die Situation beim LoadController, der so etwas wie die Steuerzentrale darstellt: konzeptionell ist er total vom Scheduler abhängig, aber seine Implementierung ist entkoppelt, wiewohl in beide Richtungen verdrahtet mit wechselseitiger Abhängigkeit. In diesem Fall muß also ein Abhängigkeitszyklus durchbrochen werden
  • + + + + +
    @@ -84269,6 +84274,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    + + + +
    @@ -98574,6 +98583,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    + + + + +
    @@ -115406,6 +115420,7 @@ std::cout << tmpl.render({"what", "World"}) << s + @@ -115736,7 +115751,8 @@ std::cout << tmpl.render({"what", "World"}) << s - + + @@ -115758,7 +115774,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -115912,7 +115928,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -115934,7 +115950,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -115950,7 +115966,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -115990,6 +116006,9 @@ std::cout << tmpl.render({"what", "World"}) << s + + + @@ -116014,8 +116033,9 @@ std::cout << tmpl.render({"what", "World"}) << s - - + + + @@ -116033,13 +116053,14 @@ std::cout << tmpl.render({"what", "World"}) << s - + + - + @@ -116095,8 +116116,7 @@ std::cout << tmpl.render({"what", "World"}) << s und zwar if layer1.isOutOfTime(now)

    - -
    +
    @@ -116111,6 +116131,63 @@ std::cout << tmpl.render({"what", "World"}) << s + + + + + + + + +

    + der betreffende Fall in der Logik fällt leer durch und wird dann zwei Ebenen darüber als Contention-Kick gedeutet (was in 99% der Fälle auch korrekt ist) +

    + +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -118189,6 +118266,32 @@ std::cout << tmpl.render({"what", "World"}) << s + + + + + + +

    + Es kann auftreten, daß eine Lastspitze den nächsten Tick über seine Deadline befördert ⟹ dann bleibt das Scheduling stecken. Aber Layer-2 hat bisher keine Möglichkeit, die Emergency auszulösen (denn das würde gegen die Layer-Ordnung verstoßen) +

    + +
    + + +
    + + + + + + + + + + + +