QP/C  7.2.1
Real-Time Embedded Framework
No Matches
Time Management

Active ObjectsSoftware Tracing

Time management available in a traditional RTOS includes delaying a calling task (delay()) or timed blocking on various kernel objects (e.g., semaphores or event flags). These blocking mechanisms are not very useful in active object-based systems where blocking is not allowed. Instead, to be compatible with the active object model of computation, time management must be based on the event-driven paradigm in which every interesting occurrence manifests itself as an event instance.

Time Events

A real-time framework manages time through Time Events (sometimes called timers). A Time Event is a UML term and denotes a point in time. At the specified time, the event occurs [UML 2.5]. The basic usage model of these time events is as follows: An active object allocates one or more time event objects (provides the storage for them). When the active object needs to arrange for a timeout, it arms one of its time events to post itself at some time in the future.

System Clock Tick

Every real-time system, including traditional blocking kernels, requires a periodic time source called the system clock tick. The system clock tick is typically a periodic interrupt that occurs at a predetermined rate, typically between 10Hz and 100Hz. You can think of the system clock tick as the "heartbeat" of the system. The actual frequency of the system clock tick depends on the desired tick resolution of your application. The faster the tick rate, the more overhead the time management implies. The system clock tick must call a special function in the QP Framework to give the framework a chance to periodically update the Time Events.

Jitter of a periodic time event firing every tick

The figure above shows in a somewhat exaggerated manner the various delays of a periodic time event programmed with one tick interval. As indicated by the varying time intervals, the time event delivery is always subject to jitter. The jitter gets worse as the priority of the recipient active object gets lower. In heavily loaded systems, the jitter might even exceed one clock tick period. In particular, a time event armed for just one tick might expire immediately because the system clock tick is asynchronous with respect to active object execution. To guarantee at least one tick timeout, you need to arm a time event for two clock ticks. Note too that time events are generally not lost due to event queuing. This is in contrast to clock ticks of a traditional RTOS, which can be lost during periods of heavy loading.



QP shall implement the Time Events


Active ObjectsSoftware Tracing