Browse Prior Art Database

REDUCING REAL- TIME DEMANDS FROM CONFIGURATION

IP.com Disclosure Number: IPCOM000009793D
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2002-Sep-19
Document File: 5 page(s) / 234K

Publishing Venue

Motorola

Related People

Jheroen Dorenbosch: AUTHOR

Abstract

When a real time application is re-configured, care must be taken that the set of the configured values used by the application remains in a valid and internally consistent state. This article proposes the use of value triplets for the configurables. Each value triplet gives visibility of the past value, future value and cut-over time of the configurable. The use of such triplets reduces real-time synchronization problems. Moreover, time intervals can be defined during which configurables can be safely changed without disturbing the application's functionality.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 25% of the total text.

MOTOROLA

TechnicalDevelopments

REDUCING REAL- TIME DEMANDS FROM CONFIGURATION

by Jheroen Dorenbosch

When a real time application is re-configured, care must be taken that the set of the configured values used by the application remains in a valid and internally consistent state. This article proposes the use of value triplets for the configurables. Each value triplet gives visibility of the past value, future value and cut-over time of the configurable. The use of such triplets reduces real-time synchronization problems. Moreover, time intervals can be defined during which configurables can be safely changed without disturbing the application's functionality.

An example of an application in which triplets may be used is a paging traffic scheduler. The general domain is that of soft and hard real-time app1ications that must be changed on-the-fly using software re-configuration.

CONFIGURATION SYNCHRONIZATION PROBLEMS

Changing the configuration of a real-time application can be non-trivial. Problems that must be solved include - in order of increasing difficulty:

1. Synchronization of changes between the tasks of the application.

2. Internal consistency of configurables.

3. Provisioning across future changes. The application must start to digest or 'provision' the change before it becomes visible externally. Hence, upcoming changes must be known well in advance.

For example, a paging scheduler may pre-assign traffic up to 45 seconds in advance. Hence an efficient scheduler needs to pre-assign messages to a new channel long before it comes onto the air. To complicate things even more, different algorithms of the same application may need a different pre-notification interval.

Motorola, Inc. 2000

4. Access to both old and new values of a configurable. Such access is often needed in scheduling applications. A typical example is the system collapse used in the Motorola FLEXTM paging protocol (Figure 1). To efficiently provision across the lowering of the FLEX collapse the scheduler application needs to know the old collapse, the new one and the cut-over time. At this level of complexity, it is no longer obvious when a configurable variable safely can be changed. Since a scheduler must meet realtime constraints, one would like to change configurables in a 'low-impact' way. In other words, one needs to find a way to de~couple the time at which the application is informed of a change from the time the application provisions across that change.

EXISTING SYNCHRONIZATION METHODS

Event loop driven architectures can solve problems 1 and 2. Each task or algorithm gets an event loop. The loops synchronize on a common barrier.

To make a change the application:

raises the barrier;

waits for all tasks to halt at the barrier;

makes the change; and removes the barrier.

Common mutexes can solve problem 2. Each configurable gets a mutex. A client algorithm that uses a set of more than one configurable defines a mutex for that set.

The application can only change a m...