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
void	invokeWorkFunction ()
void	processSchedule ()
virtual void	run (Arg)
void	scheduleRenderJob ()
void	simpleUsage ()
void	verify_LoadFactor ()
void	verify_StartStop ()

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

Additional Inherited Members
Public Member Functions inherited from Test
virtual	~Test ()=default
	this is an interface
lib::Random	makeRandGen ()
	build a dedicated new RandomGen, seeded from the default-Gen
virtual void	run (Arg arg)=0
void	seedRand ()
	draw a new random seed from a common nucleus, and re-seed the default-Gen.
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

Member Function Documentation

simpleUsage()

void simpleUsage ( )

inlineprivate

Test:

demonstrate a simple usage scenario

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

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.

verify_StartStop()

void verify_StartStop ( )

inlineprivate

Test:

get the scheduler into running state

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

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.

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.

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 steam::mobject::session::query::anonymous_namespace{fake-configrules.cpp}::entry(), Activity::GATE, Activity::INVOKE, Activity::POST, and Activity::WORKSTART.

Here is the call 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, and vault::gear::test::STAT_NODE.

Here is the call 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