RX.control – Architecture

The concept of the RX.control software, more specifically of the infrastructure software, is based on a particular Architectural Design Pattern, which has proved to be field-robust, see References. Somewhat academically, it is sometimes called a "System of Communicating State Machines".

As described under Fields of Application, the pattern refers to the architecture of a distributed application, made from multiple processes that communicate with each other and exchange data. The concept is illustrated in the following diagram. The colors refer to the layers from the Layer Model and show how the RX.control components support the application.

The main characteristics of such an architecture are:

• An application process, for example, implements the control of a device, a particular service, or a step of a data processing chain.
• Several such dedicated processes thus realize the functionality of the overall system in a modular, possibly distributed manner.
• The internal logic of an application process is determined by events that arrive as messages in a message queue and call corresponding handler functions. A state machine defines and manages the operating states of the process being driven by these events.
• Application processes communicate with messages that represent commands, responses, or notifications, and are treated as events by the recipient.
• Application processes publish data in a central in-memory database and read data from other processes from there. The initial configuration of processes is also done in this way. Processes can register themselves for notifications of changes in the database.
• With the concepts of messaging and the central database, the application processes are weakly coupled. The command and data flow can be adjusted by configuration without the need to re-compile the application.
• A central instance - the application manager - starts and configures the system of application processes after central services, such as the in-memory database, the network communication and logging have been initialized.
• At runtime, the application manager monitors the system.

Why Processes Instead of Threads?

Instead of having multiple processes, you could alternatively design an application with multi-threading, with each process corresponding to a thread. However, a multi-process solution has advantages:

• Building and deploying an application system from processes is more modular than a monolithic and very large multi-threaded application; each program can be created and installed individually. It is also possible, e.g. for testing purposes, to substitute a single program against a stub process without the need to rebuild the application.
• Managing, inspecting, debugging, etc. from the shell and tools is easier; processes are individually accessible, whereas threads are hidden inside processes.
• The signal handling of a multi-threaded application is more difficult with respect to predicting and controlling which thread is given a signal. There is also a strong dependency on the signal and on the Linux kernel version.
• Individual call arguments can be given to each process.
• The process priority and the assignment to a CPU core can be set more easily compared to the more complicated handling of user PID, kernel PID and TGID for threads.
• In addition, an application process often requires auxiliary threads, e.g for timers or background tasks. In an application where all processes are themselves created as threads, this leads to a complex thread hierarchy.

Concerning performance and resource aspects, processes and threads on Linux are only slightly different. From the kernel's point of view, both are "tasks". The convenience that interprocess communication and synchronization as well as access to global variables is easier between threads that share the same address space, does not matter much. All IPC mechanisms are also available between processes and are already provided by the RX.control infrastructure software. Conversely, when using threads, there are costs, too, e.g. for using Thread Local Storage.

Therefore, RX.control is based on a multi-process model, which gives the user the advantages and does not require any extra effort since the infrastructure software implements the required IPC mechanisms for this model as a class library and provides this functionality as an easy-to-use API.