AVIX Exchange Services offer everything you need to make Application Development manageable

Creating a full blown application can be quite challenging. Testing and integrating individual software components may require a lot of work. Every component potentially uses different interface mechanisms, tightly coupling it to other components. This makes testing challenging because test code has to be able to work with every interface mechanism used. Adding new functionality not only requires new code to be added but often many changes to existing code must be made. Combining software components running with different periods may require custom solutions to prevent a waste of valuable system resources. Think for instance of an application sampling some analog channels once per millisecond and showing these values on a ‘slow’ LCD which is updated once every 50 milliseconds. Reusing software components in another application may require many changes to this component and thus a complete retest of that component.

AVIX Exchange Services offer a solution to all these challenges. Using Exchange Services, all interfaces between software components are based on a single, uniform technology. A thread producing data just writes to an Exchange Object and is done. A thread consuming data just connects to an Exchange object and is notified when new data is written by a producer. Individual threads have no knowledge of each other and only use Exchange Objects for writing and reading data. Exchange Services are based on the proven publish-subscribe design pattern. Every individual software component is highly modular, modularity bringing many advantages. Exchange Services are fully integrated in AVIX and enhances its functionality in a way not offered by any competing product.

Want to know more? A dedicated document (AVIX_ExchangeMechanism.pdf) describes the steps required to create an application using Exchange Services. Many of the Free Demo distributions available on the AVIX Download Section contain a full blown application where the individual software components use Exchange Objects for their communication. This demo application is an implementation of the application described in AVIX_ExchangeMechanism.pdf. A second source of information is the AVIX User & Reference Guide, also available on the AVIX Download Section.

How does it work?

Exchange Services center around Exchange Objects. An Exchange Object is a thread safe global variable with dedicated access functions. Threads can read and write an Exchange Object where the integrity of the data is ensured. Exchange Object operations are atomic. This offers the basic means to transfer data from one thread to another or from one thread to many others. This is however not what makes Exchange Objects special. What is needed is a way to inform a thread that new data is written to an Exchange Object so this ‘consuming’ thread can read that data an process it. This is exactly what Exchange Objects offer. A thread wanting to be informed that new data is available ‘connects’ to an Exchange Object. When establishing the connection, the thread specifies how it will be informed of new data being written to the Exchange Object. Many different options are available. The thread requiring to be informed can use the option that optimally fits its needs.

A ‘thread message queue connection’ results in a message being send to the thread message queue of the connected thread every time new data is written to the Exchange Object. The message holds a copy of the Exchange Object content. The consuming thread is informed every time the Exchange Object is written.

A ‘thread event group connection’ results in a flag being set in the event group of the connected thread. The connected thread is informed new data is available but it is up to this thread when it reads the data. This type of connection is especially useful for user interface threads that typically have a low update rate where not every new data entity has to be shown on the connected LCD.

Many more types of connection are offered from pipe based to plain callback functions giving full control over how new data is processed. A consuming thread can choose the type of connection that best fits its requirements. Applying Exchange Services results in an unprecedented level of modularity offering many benefits, not only during initial development and testing but also when extending the application or reusing the software components.



An Example

Below two examples of an application structure are shown, left without and right with an Exchange Object. This sample application consists of an ADC thread with a timer having a one millisecond period. Every time this timer expires this thread samples some analog channels. The sampled data is used by a Comm. Thread to be send out over a communication link.  A User Interface  Thread shows the data on an LCD. Since the LCD only needs to be updated once every 50 milliseconds, the UI Thread uses its own timer to establish this period.


Non Exchange solution.

The ADC thread sends its samples to the Comm. Thread using messages. For the UI Thread a pipe is used. When the UI Thread runs because its timer expires, it reads all data from the pipe and actually only uses the last sample to show on the LCD

Exchange based solution.

When using an Exchange Object, the ADC Thread writes to this object. The Comm. Thread uses a ‘thread message queue connection’. Every write to the Exchange object results in a message being send. The UI Thread uses a ‘thread event group connection’, resulting in an event flag being set (dotted line) every time the Exchange Object is written. Only when the UI threads timer expires, it checks this flag. When set it reads the Exchange object to update the content of the LCD.


Both solutions expose the same functionality, the solution using the Exchange Object however has many advantages. The ADC thread only ‘knows’ the Exchange Object, regardless how many threads are interested in its data, where for the basic solution, the ADC thread is aware of the consumers since it explicitly has to send a message and write to a pipe. Second, the fact that the UI Thread only needs one out of many samples wastes memory in the basic solution because of the pipe, where in the Exchange Object based solution no memory is wasted. The Exchange Object only holds the last sample and it is up to the UI Thread when it reads the Exchange Object. Finally when testing the application, for the basic solution, test software is confronted with having to use messages and pipes, just like the ADC Thread does. For the Exchange Object based solution all that needs to be done is write to the Exchange Object which is the same for every component as long as Exchange Objects are used as the single interface mechanism, which is what they are intended for in the first place.

AVIX-RT © 2006-2015, All Rights Reserved

Legal Disclaimer

Privacy Policy