+ ...ich hatte diesen Fix nur oberflächlich getestet, und dabei übersehen, daß eine Assertion ansprechen kann (sogar sehr wahrscheinlich einmal ansprechen wird, sobald der Reparatur-Mechanismus eine größtere Strecke zurücklegt). Das ist aber kein Bug im eigentlichen Reparatur-/reLink-Mechanismus; dieser funktioniert präzise, wie ich nochmals im einzelnen mit dem Debugger nachvollziehen konnte. +
+ + ++ wenn eine Deadline überfahren wurde, ist ein weiterer Zugriff auf den Extend als _undefined behaviour_ zu betrachten. Das gilt auch für das AllocatorHandle, das man früher mal für eine bestimmte Deadline bekommen hat; dieses kann man sehr wohl weiterhin verwenden (solange die Deadline noch in der Zukunft liegt). Konkreter Fall: später noch eine Dependency anhängen. Wenn der Anker dieser Dependecy zu dem Zeitpunkt bereits ausgeführt oder invalidiert wurde, ist man selber schuld! +
+ ++ und damit nicht über eine Abweichung der Job-Zeiten in den Formfaktor eingehen +
+ ++ naja... die ist unterirdisch +
+ ++ zur Erinnerung: in einer Serie machen wir ja eine Art Konvergenz auf einen effektiven Form-Faktor hin. Mit den Ergebnissen eines Laufes wird für den nächsten Lauf nachjustiert; der von außen vorgegebene (nominelle) Streß-Faktor bleibt, aber die tatsächliche Dichte wird so optimiert, daß die dann effektiv diesem Faktor entspricht. Im Zuge dieser Anpassung wird anscheinend das Schedule jeweils etwas verdichtet, und die erreichte Concurency fällt (von etwas über 2 auf 1.6 zuletzt) +
+ ++ zumindest nach den inzwischen vorliegenden Beobachtungen aus dem Param-Range-Setup +
+ ++ extent-family.hpp:356 +
+ ++ ...damals allerdings aus einem ganz anderen Kontext, der inzwischen durch einen Umbau im Scheduler behoben ist/sein sollte. +
+ ++ »investigateWorkProcessing« +
++ ∅conc:7.29344 +
++ ∅conc:6.53128 +
++ ∅conc:6.24495 +
++ ∅conc:6.082 +
++ PRECONDITION: extent-family.hpp:356: thread_9: access: (isValidPos (idx)) +
+ ++ 0000000609: PRECONDITION: extent-family.hpp:356: thread_9: access: (isValidPos (idx)) +
++ vault::mem::ExtentFamily<vault::gear::Activity, 500ul>::access(unsigned long) const+0xdd +
++ vault::mem::ExtentFamily<vault::gear::Activity, 500ul>::IdxLink::yield() const+0x26 +
++ vault::mem::ExtentFamily<vault::gear::Activity, 500ul>::IdxLink::validatePos(vault::mem::ExtentFamily<vault::gear::Activity, 500ul>::Extent*)+0x52 +
++ vault::gear::BlockFlow<vault::gear::blockFlow::RenderConfig>::StorageAdaptor::iterNext()+0x23 +
++ lib::IterableDecorator<vault::gear::blockFlow::Epoch<vault::mem::ExtentFamily<vault::gear::Activity, 500ul> >, vault::gear::BlockFlow<vault::gear::blockFlow::RenderConfig>::StorageAdaptor>::operator++()+0x20 +
++ vault::gear::BlockFlow<vault::gear::blockFlow::RenderConfig>::AllocatorHandle::claimSlot()+0x228 +
++ vault::gear::Activity& vault::gear::BlockFlow<vault::gear::blockFlow::RenderConfig>::AllocatorHandle::create<vault::gear::Activity::Verb>(vault::gear::Activity::Verb&&)+0x2e +
++ vault::gear::activity::Term::appendNotificationTo(vault::gear::activity::Term&, bool)+0x2f +
++ vault::gear::ScheduleSpec::linkToPredecessor(vault::gear::ScheduleSpec&, bool)+0x68 +
++ vault::gear::test::TestChainLoad<8ul>::ScheduleCtx::continuation(unsigned long, unsigned long, unsigned long, bool)+0x2ef +
++ vault::gear::test::TestChainLoad<8ul>::ScheduleCtx::performRun()::{lambda(unsigned long, unsigned long, unsigned long, bool)#3}::operator()(unsigned long, unsigned long, unsigned long, bool) const+0x40 +
++ std::_Function_handler<void (unsigned long, unsigned long, unsigned long, bool), vault::gear::test::TestChainLoad<8ul>::ScheduleCtx::performRun()::{lambda(unsigned long, unsigned long, unsigned long, bool)#3}>::_M_invoke(std::_Any_data const&, unsigned long&&, std::_Any_data const&, std::_Any_data const&, bool&&)+0x86 +
++ std::function<void (unsigned long, unsigned long, unsigned long, bool)>::operator()(unsigned long, unsigned long, unsigned long, bool) const+0x90 +
++ vault::gear::test::RandomChainPlanFunctor<8ul>::invokeJobOperation(lumiera_jobParameter_struct const&)+0x2ca +
++ vault::gear::Activity::invokeFunktor(lib::time::Time)+0x740 +
++ vault::gear::activity::Proc vault::gear::Activity::activate<vault::gear::Scheduler::ExecutionCtx>(lib::time::Time, vault::gear::Scheduler::ExecutionCtx&)+0x70 +
++ vault::gear::activity::Proc vault::gear::ActivityLang::activateChain<vault::gear::Scheduler::ExecutionCtx>(vault::gear::Activity*, vault::gear::Scheduler::ExecutionCtx&)+0x4e +
++ vault::gear::activity::Proc vault::gear::ActivityLang::dispatchChain<vault::gear::Scheduler::ExecutionCtx>(vault::gear::Activity*, vault::gear::Scheduler::ExecutionCtx&)+0x68 +
++ vault::gear::Scheduler::doWork()::{lambda(vault::gear::ActivationEvent)#1}::operator()(vault::gear::ActivationEvent) const+0x4d +
++ vault::gear::SchedulerCommutator::dispatchCapacity<vault::gear::Scheduler::doWork()::{lambda(vault::gear::ActivationEvent)#1}, vault::gear::Scheduler::doWork()::{lambda()#2}>(vault::gear::SchedulerInvocation&, vault::gear::LoadController&, vault::gear::Scheduler::doWork()::{lambda(vault::gear::ActivationEvent)#1}, vault::gear::Scheduler::doWork()::{lambda()#2})::{lambda()#2}::operator()() const+0x8f +
++ vault::gear::SchedulerCommutator::WorkerInstruction vault::gear::SchedulerCommutator::WorkerInstruction::performStep<vault::gear::SchedulerCommutator::dispatchCapacity<vault::gear::Scheduler::doWork()::{lambda(vault::gear::ActivationEvent)#1}, vault::gear::Scheduler::doWork()::{lambda()#2}>(vault::gear::SchedulerInvocation&, vault::gear::LoadController&, vault::gear::Scheduler::doWork()::{lambda(vault::gear::ActivationEvent)#1}, vault::gear::Scheduler::doWork()::{lambda()#2})::{lambda()#2}>(vault::gear::LoadController)+0x1f +
++ vault::gear::activity::Proc vault::gear::SchedulerCommutator::dispatchCapacity<vault::gear::Scheduler::doWork()::{lambda(vault::gear::ActivationEvent)#1}, vault::gear::Scheduler::doWork()::{lambda()#2}>(vault::gear::SchedulerInvocation&, vault::gear::LoadController&, vault::gear::Scheduler::doWork()::{lambda(vault::gear::ActivationEvent)#1}, vault::gear::Scheduler::doWork()::{lambda()#2})+0xc5 +
++ vault::gear::Scheduler::doWork()+0x3d +
++ vault::gear::Scheduler::Setup::doWork()+0x1c +
++ vault::gear::work::Worker<vault::gear::Scheduler::Setup>::pullWork()+0x26 +
+ ++ linkToPredecessor() +
+ ++ tritt reproduzierbar auf ab Load=4ms +
+ ++ alloziert wurde auf dem predecessor-Term +
+ ++ ...das ist ohnehin etwas kreativ +
+ + ++ dieser hängt an der Deadline +
+ + ++ Der Allokator in sich ist robust; die Deadline beschreibt nur einen Nutzungs-Kontrakt; sie ist zwar im Gate des Blocks gespeichert, aber für den Allokator nur maßgeblich zur Suche des passenden Blocks. Das weitere Nutzungs-Muster muß auf einer höheren Ebene gewährleistet sein. +
+ + +