Scheduler-test: bugfix in computation-load

...this one was quite silly: obviously we need a separate instance
of the memory block ''per invocation'', otherwise concurrent invocations
would corrupt each other's allocation. The whole point of this variant
of the computation-load is to access a ''private'' memory block...

tests/vault/gear/scheduler-stress-test.cpp

@@ -296,7 +296,7 @@ SHOW_EXPR(micros);
           // Adapted Schedule----------
           TRANSIENTLY(work::Config::COMPUTATION_CAPACITY) = 4;
           auto LOAD_BASE = 500us;
-          double stressFac = 0.6;
+          double stressFac = 0.5;
           uint concurrency = 4;
           
           // Build-Performance-test-setup--------
@@ -307,6 +307,7 @@ SHOW_EXPR(micros);
           auto testSetup =
             testLoad.setupSchedule(scheduler)
                     .withLoadTimeBase(LOAD_BASE)
+                    .withLoadMem()
                     .withJobDeadline(50ms)
                     .withUpfrontPlanning()
                     .withAdaptedSchedule(stressFac, concurrency);

tests/vault/gear/test-chain-load.hpp

@@ -1255,8 +1255,6 @@ namespace test {
     {
       using Sink = volatile size_t;
       
-      lib::UninitialisedDynBlock<Sink> memBlock_{};
-      
       static double&
       computationSpeed (bool mem)     ///< in iterations/µs
         {
@@ -1346,12 +1344,12 @@ namespace test {
       causeMemProcessLoad (uint scaleStep)
         {
           auto [siz,round] = allocNeeded (scaleStep);
-          memBlock_.allocate(siz);
-          ++*memBlock_.front();
+          lib::UninitialisedDynBlock<Sink> memBlock{siz};
+          ++*memBlock.front();
           for ( ; 0 < round; --round)
-            for (size_t i=0; i<memBlock_.size()-1; ++i)
-              memBlock_[i+1] += memBlock_[i];
-          ++*memBlock_.back();
+            for (size_t i=0; i<memBlock.size()-1; ++i)
+              memBlock[i+1] += memBlock[i];
+          ++*memBlock.back();
         }
       
       double