diff --git a/src/vault/gear/scheduler.hpp b/src/vault/gear/scheduler.hpp index 87831a401..0e3d012ac 100644 --- a/src/vault/gear/scheduler.hpp +++ b/src/vault/gear/scheduler.hpp @@ -207,6 +207,8 @@ namespace gear { ScheduleSpec linkToSuccessor (ScheduleSpec&); ScheduleSpec linkToPredecessor(ScheduleSpec&); + private: + void maybeBuildTerm(); }; @@ -544,9 +546,7 @@ namespace gear { ScheduleSpec::post() { // protect allocation // auto guard = theScheduler_->layer2_.requireGroomingTokenHere();//////////////////////////////////////TODO can we avoid that? - term_ = move( - theScheduler_->activityLang_ - .buildCalculationJob (job_, start_,death_)); + maybeBuildTerm(); //set up new schedule by retrieving the Activity-chain... theScheduler_->postChain ({term_->post(), start_ , death_ @@ -555,9 +555,24 @@ namespace gear { return move(*this); } + /** + * @internal if not done yet, then construct the Activity-Language term + * describing the schedule according to the parameters set thus far. + */ + inline void + ScheduleSpec::maybeBuildTerm() + { + if (term_) return; + term_ = move( + theScheduler_->activityLang_ + .buildCalculationJob (job_, start_,death_)); + } + inline ScheduleSpec ScheduleSpec::linkToSuccessor (ScheduleSpec& succSpec) { + this->maybeBuildTerm(); + succSpec.maybeBuildTerm(); term_->appendNotificationTo (*succSpec.term_); return move(*this); } @@ -565,6 +580,8 @@ namespace gear { inline ScheduleSpec ScheduleSpec::linkToPredecessor (ScheduleSpec& predSpec) { + predSpec.maybeBuildTerm(); + this->maybeBuildTerm(); predSpec.term_->appendNotificationTo (*term_); return move(*this); } diff --git a/tests/vault/gear/test-chain-load.hpp b/tests/vault/gear/test-chain-load.hpp index 27b168c34..4126b20cc 100644 --- a/tests/vault/gear/test-chain-load.hpp +++ b/tests/vault/gear/test-chain-load.hpp @@ -1697,9 +1697,13 @@ namespace test { schedule_[idx] = scheduler_.defineSchedule(calcJob (idx,level)) .manifestation(manID_) .startTime (jobStartTime(level, idx)) - .lifeWindow (deadline_) - .post(); - } + .lifeWindow (deadline_); + Node& n = chainLoad_.nodes_[idx]; + if (isnil (n.pred) + or schedDepends_) + schedule_[idx].post(); + }// Node with dependencies will be triggered by NOTIFY + // and thus must not necessarily be scheduled explicitly. /** Callback: define a dependency between scheduled jobs */ void diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index b74305eea..3fecb6a2e 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -107929,22 +107929,22 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + - - + + - - + + @@ -107952,14 +107952,26 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + +
- - + + + + + + + + + + + @@ -107971,16 +107983,35 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - - - + + - - - + + + + + + + + + + + + + +

+ anders kann ich mir das nicht erklären, denn es ist ja nun immer nur eine kleine Zahl an Einträgen in der Queue, d.h. es besteht durchaus die Gefahr, daß sich Worker schlafen legen, weil die Queue scheinbar leer ist. Tatsächlich passiert das aber nur in den Abschnitten mit geringer Parallelität (ja der Doppel-Strang wird nun nur von einem Worker bearbeitet) +

+ + +
+
+
+
+ + + @@ -107989,7 +108020,23 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

+ +
+ + + + + + + +

+ muß dann die Info über zwei Ebenen durchreichen...? +

+ + +
+
@@ -107998,15 +108045,6 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - - - - - - -
@@ -110626,6 +110664,26 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + +

+ nachdem ich aber nur noch per NOTIFY triggere, +

+

+ ist die beobachtbare Verzögerung nun im Gegenteil oft zu kurz. +

+

+ Nur an einer Stelle mit vielen aktiven Workern, treten mal wieder 2ms auf +

+ + +
+ +