Solving RTOS (Real Time Operating System) Limitations with Active Objects in Embedded Systems

In embedded systems, Real-Time Operating Systems (RTOS) are designed to synchronize thread execution with specific events, often through blocking and waiting for designated occurrences. However, this approach has its drawbacks. Blocked threads become unresponsive to events they haven’t explicitly waited for, leading to the creation of more threads to handle additional events. But this growing number of threads quickly becomes difficult to handle.

Even more concerning is the fact that new threads often require access to the same data, peripherals, or resources as existing threads, leading to resource sharing among threads. While RTOS offers various mutual exclusion mechanisms to address this issue, many of these mechanisms introduce further blocking and may result in secondary adverse effects such as priority inversion, deadlock, and starvation. These complexities significantly complicate system management and can lead to missed real-time deadlines, ultimately leading to system failure.

Image source: state-machine.com

Table of Content

Best Practices of Concurrent Programming:

To tackle these challenges, there are some best practices in concurrent programming that programmers employ. They include:

Isolate data and resources: Threads should refrain from sharing data or resources with one another to mitigate shared-state concurrency issues. By avoiding sharing, the need for mutual exclusion is eliminated. However, while avoiding sharing sounds simple, the question arises: How can threads communicate and synchronize without sharing? This dilemma is addressed in the second-best practice.
Communicate among threads via asynchronous events: This principle encompasses two critical concepts events and asynchronous communication. Events are crafted data specifically intended for communication. They convey information about specific occurrences, such as a timeout event or a button press. Asynchronous communication involves senders posting events to recipients without waiting in-line, meaning they don’t block until the event is processed. Thus, the second-best practice aims to eliminate synchronization by blocking.
Leverage event-driven design: Organising thread activities around an event loop or message pump fosters an event-driven design paradigm. This strategy aligns with the objective of minimizing blocking in RTOS environments, ensuring threads remain responsive to various events without compromising system efficiency.

The Active Object Design Pattern:

Active Objective:

Active Objects represent a design pattern widely employed in embedded systems programming, particularly in scenarios where concurrency and responsiveness are critical. Active Objects encapsulate both data and behavior within an object, operating asynchronously and independently from other parts of the system. Central to their design are private threads and event queues, facilitating non-blocking communication and ensuring efficient resource management.

Image source: state-machine.com

Active Objects and Best Practices:

Active Objects serve as the embodiment of these best practices in concurrent programming, encompassing all three principles discussed earlier. By encapsulating private data, maintaining a private thread, and employing event queues, Active Objects ensure the isolation of resources and the elimination of shared-state concurrency issues. Interactions with Active Objects rely solely on event posting, enabling asynchronous communication, and eliminating the need for blocking synchronization. The event processing within an Active Object’s private thread guarantees strict encapsulation of data, thereby enhancing system concurrency and robustness. Additionally, Active Objects promote modular design and integration of event-driven behavior, making them an invaluable asset for embedded system developers seeking optimal performance and reliability. Thus, Active Objects stands as a powerful design solution that embodies the core principles of concurrent programming in embedded systems.

Conclusion:

In conclusion, the Active Object pattern embodies a paradigm that leverages the flexibility and modularity of event-driven programming. While an Active Object framework relies on essential services from traditional Real-Time Operating Systems (RTOS), such as threads and message queues, it diverges from conventional RTOS by strictly prohibiting blocking mechanisms. Consequently, developers are tasked with providing all other necessary elements for effective event-driven programming.