scheduler-commutator.hpp File Reference

Go to the source code of this file.

Description

Layer-2 of the Scheduler: coordination and interaction of activities.

This is the upper layer of the implementation and provides high-level functionality. Rendering Activities are represented as a chain of Activity verbs (records), which are interconnected to create a low-level execution language. The prime Activity obviously is to Activity::Verb::INVOKE a JobFunctor encapsulating media processing operations; further Activity verbs provide building blocks for execution logic, to check preconditions, notify follow-up tasks after calculation results are available and to control the scheduling process itself. The Scheduler as a service allows to execute Activities while observing time and dependency constraints and in response to external events (notably after IO callback).

Activity records are tiny data records (standard layout and trivially constructible); they are comprised of a verb tag and a union for variant parameter storage, and will be managed elsewhere relying on the BlockFlow allocation scheme. Within the scheduler queues and execution environment it is thus sufficient to pass Activity*. While the actual media processing is performed concurrently by a WorkForce with a pool of actively pulling workers, any allocations and changes to internal state and data structures of the Scheduler itself must be protected against data corruption by concurrency. The intended usage scenario involves media data computations which are by several orders of magnitude more expensive than all the further internal management operations. Thus the design of the Scheduler relies on simple mutual exclusion (implemented by atomic lock, see SchedulerCommutator::groomingToken_). Each worker in search for the next task will first acquire the Grooming-Token, then execute some internal Activities until encountering an actual media computation JobFunctor. At this point, the execution will switch from »grooming mode« into work mode; the worker drops the Grooming-Token at this point and will then refrain from touching any further Scheduler internals. Finally, after completion of the current Render Job, the worker will again contend for the Grooming-Token to retrieve more work.

In typical usage, Layer-2 of the Scheduler will perform the following operations

• accept and enqueue new task descriptions (as chain-of-Activities)
• retrieve the most urgent entry from Layer-1
• silently dispose of any outdated entries
• use the Activity Language environment to perform the retrieved chain within some worker thread; this is called dispatch The main entrance point into this implementation is the #postChain function.

  See also

  SchedulerCommutator::acquireGroomingToken()

  SchedulerCommutator::findWork()

  SchedulerCommutator::postChain()

  SchedulerCommutator_test

  scheduler.hpp usage

Definition in file scheduler-commutator.hpp.

#include "vault/common.hpp"
#include "vault/gear/activity.hpp"
#include "vault/gear/scheduler-invocation.hpp"
#include "vault/gear/load-controller.hpp"
#include "vault/gear/activity-lang.hpp"
#include "lib/time/timevalue.hpp"
#include "lib/format-string.hpp"
#include "lib/nocopy.hpp"
#include <thread>
#include <atomic>

Classes
class	SchedulerCommutator
	Scheduler Layer-2 : execution of Scheduler Activities. More...
class	SchedulerCommutator::ScopedGroomingGuard
struct	SchedulerCommutator::WorkerInstruction
	monad-like step sequence: perform sequence of steps, as long as the result remains activity::PASS More...

Functions
auto	thisThread ()
	convenient short-notation, also used by SchedulerService

Variables
microseconds	GROOMING_WAIT_CYCLE {70us}
	wait-sleep in case a thread must forcibly acquire the Grooming-Token

Namespaces
	vault
	Vault-Layer implementation namespace root.
	vault::gear
	Active working gear and plumbing.