Xentara v1.0
User Manual
Scheduling Tasks

Table of Contents

Xentara provides a sophisticated mechanism for scheduling and coordinating tasks. Tasks are provided by different elements in the Xentara model.

Tasks can be executed in two different ways:

  • at regular intervals using a timer, or
  • in response to an event, like a change in the value of a data point.

Execution Pipelines

Structure of a Pipeline

Tasks are grouped together into pipelines. Each pipeline is attached to a single timer or event, and executed when the timer elapses or the event fires.

An execution pipeline consists of a number of check points connected by segments Each segment consists of one or more tasks, executed in sequence. The simplest possible pipeline just consists of a single segment joining two check points:

Image 1: simple pipeline

Pipelines support parallel execution of segments. A pipeline using parallel execution may look like this, for example:

Image 2: parallel pipeline

Pipelines can have multiple check points. A more complex pipeline may look like this:

Image 3: complex pipeline

Pipeline Segments

A pipeline segment ist just a bunch of tasks that are executed one after the other in a single thread. A pipeline segment always starts and ends at a check point.

In image 3 above, there are three pipeline segments:

  1. Segment 1: Task 1a 🠖 Task 1b 🠖 Task 1c
  2. Segment 2: Task 2a 🠖 Task 2b
  3. Segment 3: Task 3a 🠖 Task 3b

Individual segments (like Segment 1 and Segment 2) can be executed in parallel. The tasks within each segment are always executed sequentially, however.

Segments are executed using a thread pool located the corresponding execution track (see below). The number of threads in the thread pool determine how many pipeline segments can be executed in parallel. If the thread pool does not have enough threads, some pipeline segments will be executed sequentially, even if the structure of the pipeline would otherwise allow them to be executed in parallel.

Check Points

A check point is a synchronization point that waits for a number of pipeline segments to all be finished. It then starts another group of segments. In image 3 above, there are three check points:

  1. Check Point 1: This check point starts Segment 1 and Segment 2 in parallel
  2. Check Point 2: This check point waits for Segment 1 and Segment 2 to finish, and then starts Segment 3
  3. Check Point 3: This check points waits for Segment 3 to finish

After the last check point (Check Point 3) has been reached, the pipeline is finished, and the next pipeline can start.

Segments can skip check points, if desired:

Image 4: segment that skips a check point

In the image above, Segment 4 extends between Check Point 1 and Check Point 3, skipping Check Point 2. Check Point 2 will start Segment 3 even if the new Segment 4 has not completed yet. Check Point 3 will then wait for Segment 3 and Segment 4 to finish, before ending the pipeline.

Execution Tracks

The individual pipelines are divided into one or more execution tracks. The pipelines within each track are alwas executed one after the other, and are never allowed to overlap. Pipelines in different tracks are allowed to execute simultaneousy.

Image 5: separate execution tracks

The image above shows two separate execution tracks, each with a timer. The pipelines of the two timers are allowed to overlap, because they are in different tracks. The event pipeline, however, does not overlap the timer in the same track. Instead, the event pipeline is delayed until the timer pipeline has finished. Similarly, the next execution of the timer pipeline is delayed until the event pipeline has finished.

The execution track also contains the thread pool used to execute the individual pipelines.

Timers

A timer allows you to execute tasks at regular intervals. You can define any number of timers, each with different scheduling parameters.

Timers are scheduled using two parameters:

  • The interval determines how often the timer will fire.
  • The reference time determines when exactly the timer will fire.

The reference time is used to define exactly when the timer will fire. A timer with an interval of 1 second, for example, might always fire at the full second, so at 12:00:00.000, 12:00:01.000, 12:00:02.000, etc. Or, it might fire on every half second, so at 12:00:00.500, 12:00:01.500, 12:00:02.500, etc. Both these timers would have the same interval, but different reference times.

The reference time of a timer is simply an arbitrary point in time at which the timer should fire. It can be a time in the future, or a time in the past. The exact time is not relevant, it is simply used mathematically to calculate when exactly the timer should fire.

To specify that a 1 second timer should fire at every full second, for example, you could specify any date and time with a full second, either in the past or in the future. A possible reference time would be 1 January 2001, 00:00:00.000 UTC, for example. But any other time with a full second would accomplish the same thing, like 1 January 1970, 00:00:00.000 UTC or 22 August 2021, 11:30:00.000 UTC, or even 24 December 2384, 19:33:54.000 UTC.

A timer triggers the execution of a pipeline of tasks when it fires.

Events

An Event triggers the execution of a pipeline whenever a certain event is raised by a certain element in the Xentara model.