From 5b62438eb404e20762a9f2ff6109c7cf54022064 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 10 Apr 2024 20:04:53 +0200 Subject: [PATCH] =?UTF-8?q?Scheduler-test:=20investigate=20logic=20problem?= =?UTF-8?q?=20related=20to=20the=20=C2=BBTick=C2=AB=20deadline?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In the end, I decided that it ''is to early to decide anything'' in this respect... The actual situation encountered is a **Catch-22**: * in its current form, the »Tick« handler detects compulsory jobs beyond deadline * since such a Job ''must not be touched anymore,'' there is no way scheduling can proceed * so this would constitute a ''Scheduler Emergency'' All fine — just the »Tick« handler ''itself is a compulsory job'' — and being a job, it can well be driven beyond its deadline. In fact this situation was encountered as part of stress testing. Several mitigations or real solutions are conceivable, but in the end, too little is known yet regarding the integration of the scheduler within the Engine Thus I'll marked the problematic location and opened #1362 --- src/vault/gear/scheduler-commutator.hpp | 10 +- src/vault/gear/scheduler.hpp | 6 ++ wiki/thinkPad.ichthyo.mm | 131 +++++++++++++++++++++--- 3 files changed, 130 insertions(+), 17 deletions(-) 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) +

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