Lumiera  0.pre.03
»edit your freedom«
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 73 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 void run (Arg arg)=0
 

Member Function Documentation

◆ simpleUsage()

void simpleUsage ( )
inlineprivate
Test:
demonstrate a simple usage scenario

Definition at line 91 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 129 of file scheduler-service-test.cpp.

◆ verify_StartStop()

void verify_StartStop ( )
inlineprivate
Test:
get the scheduler into running state

Definition at line 140 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 184 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 329 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 475 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 546 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: