SchedulerService_test Class Reference

Description

Test:

Scheduler component integration test: use the service API for state control and to add Jobs and watch processing patterns.

See also

SchedulerActivity_test

SchedulerInvocation_test

SchedulerCommutator_test

SchedulerLoadControl_test

Definition at line 64 of file scheduler-service-test.cpp.

Private Member Functions
virtual void	run (Arg)
void	simpleUsage ()
void	verify_StartStop ()
void	verify_LoadFactor ()
void	invokeWorkFunction ()
void	scheduleRenderJob ()
void	processSchedule ()

Static Private Member Functions
static void	postNewTask (Scheduler &scheduler, Activity &chain, Time start)

Additional Inherited Members
Static Public Member Functions inherited from Test
static string	firstTok (Arg)
	conveniently pick the first token from the argument line
static uint	firstVal (Arg, uint=1)
	conveniently use some number given as argument, with optional default
Public Member Functions inherited from Test
virtual	~Test ()=default
	this is an interface
virtual void	run (Arg arg)=0
void	seedRand ()
	draw a new random seed from a common nucleus, and re-seed the default-Gen.
lib::Random	makeRandGen ()
	build a dedicated new RandomGen, seeded from the default-Gen

Member Function Documentation

run()

virtual void run ( Arg  )

inlineprivatevirtual

Definition at line 68 of file scheduler-service-test.cpp.

References SchedulerService_test::invokeWorkFunction(), SchedulerService_test::processSchedule(), SchedulerService_test::scheduleRenderJob(), Test::seedRand(), SchedulerService_test::simpleUsage(), SchedulerService_test::verify_LoadFactor(), and SchedulerService_test::verify_StartStop().

Here is the call graph for this function:

simpleUsage()

void simpleUsage ( )

inlineprivate

Test:

demonstrate a simple usage scenario

Definition at line 83 of file scheduler-service-test.cpp.

References Time::ANYTIME, vault::gear::test::onetimeCrunch(), and vault::gear::watch().

Referenced by SchedulerService_test::run().

Here is the call graph for this function:

Here is the caller graph for this function:

postNewTask()

static void postNewTask ( Scheduler &  scheduler, Activity &  chain, Time  start  )

inlinestaticprivate

helper to inject a new task into the Scheduler, without also activating WorkForce and load control.

Remarks

this class is declared friend by the Scheduler to grant this kind of »implementation backdoor« access; the function defined there does essentially the same than Scheduler::postChain()

Definition at line 121 of file scheduler-service-test.cpp.

References Scheduler::layer1_, Scheduler::layer2_, and SchedulerCommutator::postChain().

Referenced by SchedulerService_test::invokeWorkFunction(), SchedulerService_test::verify_LoadFactor(), and SchedulerService_test::verify_StartStop().

Here is the call graph for this function:

Here is the caller graph for this function:

verify_StartStop()

void verify_StartStop ( )

inlineprivate

Test:

get the scheduler into running state

Definition at line 132 of file scheduler-service-test.cpp.

References Activity::FEED, RealClock::now(), SchedulerService_test::postNewTask(), and vault::gear::watch().

Referenced by SchedulerService_test::run().

Here is the call graph for this function:

Here is the caller graph for this function:

verify_LoadFactor()

void verify_LoadFactor ( )

inlineprivate

Test:

verify the scheduler processes scheduled events, indicates current load and winds down automatically when falling empty.

• schedule short bursts of single FEED-Activities
• these actually do nothing and can be processed typically < 5µs
• placing them spaced by 1µs, so the scheduler will build up congestion
• since this Activity does not drop the »grooming-token«, actually only a single worker will process all Activities in a single peak
• after the peak is done, the load indicator will drop again
• when reaching the scheduler »tick«, the queue should be empty and the scheduler will stop active processing
• the main thread (this test) polls every 50µs to observe the load
• after 2 seconds of idle-sleeping, the WorkForce is disengaged
• verify the expected load pattern

Definition at line 176 of file scheduler-service-test.cpp.

References Activity::FEED, MARK_TEST_FUN, RealClock::now(), SchedulerService_test::postNewTask(), and vault::gear::watch().

Referenced by SchedulerService_test::run().

Here is the call graph for this function:

Here is the caller graph for this function:

invokeWorkFunction()

void invokeWorkFunction ( )

inlineprivate

Test:

verify visible behaviour of the work-pulling function

• use a rigged Activity probe to capture the schedule time on invocation
• additionally perform a timing measurement for invoking the work-function
• invoking the Activity probe itself costs 50...150µs, Scheduler internals < 50µs
• this implies we can show timing-delay effects in the millisecond range
• demonstrated behaviour
  • an Activity already due will be dispatched immediately by post()
  • an Activity due at the point when invoking the work-function is dispatched
  • while queue is empty, the work-function returns immediately, indicating sleep
  • invoking the work-function, when there is still some time span up to the next planned Activity, will cause a targeted sleep, returning shortly after the next schedule. Entering then again will cause dispatch of that activity.
  • if the work-function dispatches an Activity while the next entry is planned for some time ahead, the work-function will likewise go into a targeted sleep and only return at or shortly after that next planned time entry
  • after dispatching an Activity in a situation with no follow-up work, the work-function inserts a targeted sleep of random duration, to re-shuffle the rhythm of sleep cycles
  • when the next planned Activity was already »tended for« (by placing another worker into a targeted sleep), further workers entering the work-function will be re-targeted by a random sleep to focus capacity into a time zone behind the next entry.

Note

Invoking the Activity probe itself can take 50..150µs, due to the EventLog, which is not meant to be used in performance critical paths but only for tests, because it performs lots of heap allocations and string operations. Moreover, we see additional cache effects after an extended sleep period.

Definition at line 321 of file scheduler-service-test.cpp.

References lib::test::benchmarkTime(), ActivityDetector::buildActivationProbe(), ActivityDetector::invokeTime(), MARK_TEST_FUN, RealClock::now(), vault::gear::activity::PASS, SchedulerService_test::postNewTask(), vault::gear::activity::WAIT, and vault::gear::watch().

Referenced by SchedulerService_test::run().

Here is the call graph for this function:

Here is the caller graph for this function:

scheduleRenderJob()

void scheduleRenderJob ( )

inlineprivate

Test:

Schedule a render job through the high-level Job-builder API.

• use the mock Job-Functor provided by the ActivityDetector
• manipulate the WorkForce to prevent it from scaling up
• this allows us to investigate the queue entry created through the public regular API for scheduling Render Jobs
• after that, the test manually invokes the work-pulling function and verifies the mock Job-Functor has been invoked
• note however that this time a complete Activity chain was created, including a Gate and all state transitions, since we used the high-level API of the SchedulerService

Definition at line 467 of file scheduler-service-test.cpp.

References ActivityMatch::arg(), ActivityMatch::beforeInvocation(), ActivityDetector::buildMockJob(), Config::COMPUTATION_CAPACITY, Activity::GATE, ActivityDetector::incrementSeq(), Activity::INVOKE, RealClock::now(), vault::gear::activity::PASS, Activity::POST, TRANSIENTLY, ActivityDetector::verifySeqIncrement(), vault::gear::watch(), and Activity::WORKSTART.

Referenced by SchedulerService_test::run().

Here is the call graph for this function:

Here is the caller graph for this function:

processSchedule()

void processSchedule ( )

inlineprivate

Test:

schedule and process a complete work load

• use a complex computation structure generated by TestChainLoad
• dispatch 64 jobs, each depending more or less on its predecessors
• processing proceeds first in two parallel chains, then joins and forks again into a massive overload towards the end.
• each level of jobs is scheduled 1ms apart
• some jobs use a computation weight ranging form 500µs to 1.5ms
• at the end, both a single threaded computation and the computation processed by the scheduler must yield the same result hash, which is computed for each job by combining its predecessor hashes.

Definition at line 538 of file scheduler-service-test.cpp.

References TestChainLoad< maxFan >::buildTopology(), TestChainLoad< maxFan >::computeGraphStatistics(), TestChainLoad< maxFan >::configureShape_chain_loadBursts(), MARK_TEST_FUN, vault::gear::test::STAT_FORK, vault::gear::test::STAT_JOIN, vault::gear::test::STAT_NODE, and vault::gear::watch().

Referenced by SchedulerService_test::run().

Here is the call graph for this function:

Here is the caller graph for this function:

Inheritance diagram for SchedulerService_test:

Collaboration diagram for SchedulerService_test:

---

The documentation for this class was generated from the following file:

• scheduler-service-test.cpp