- 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.
|
virtual void | run (Arg arg)=0 |
|
◆ simpleUsage()
◆ postNewTask()
◆ verify_StartStop()
void verify_StartStop |
( |
| ) |
|
|
inlineprivate |
◆ 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 |
◆ processSchedule()
- 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.
The documentation for this class was generated from the following file: