Deterministic Asynchronous Software Systems
We want our Asynchronous Software Systems to be Deterministic right?
Deterministic means that for a given sequence of input data, the output data will be the same each time, i.e. the software is predictable.
A highly desirable characteristic, I’m sure most people will agree, especially of high-integrity or safety-critical or embedded software.
Asynchronous software systems are software systems that run whenever they are able to, irrespective of what other systems are doing.
A software system typically comprises multiple processes.
If all of these are deterministic, then the whole system is deterministic — hurrah!
But if just one process is non-deterministic, then like a drop of ink in a glass of water, it can pollute the whole system, affecting all the processes with which it communicates. Most of the time, the system may work as expected and even consistently pass its regression tests, but occasionally erratic behaviour may be observed.
One of the possible causes of non-deterministic behaviour between asynchronous processes is inter-process communication.
The problem is that because the processes are asynchronous, the messages between then may arrive at different times on different program runs, causing different behaviour. For example, if one process detects changes in a sensor and another process emits a message with a count of sensor changes, then there is a possibility that the count may differ on some runs. This could be because of an intervening interrupt, or some other sensor changing causing additional processing in another process which in turn causes a delay which affects the output of the sensor counting process.
It’s a thorny issue.
Adding yet more stringent timing and interrupt-driven methods may solve the issue, or simply push further down into the weeds and hide it so that it is less likely to occur.As an alternative solution, consider making your asynchronous system err.. synchronous!
This means a very simple, round-robin, scheduler, processes suspending themselves when they have nothing to do, no (event driving) interrupts, no pre-emption…
Basically, it’s like going back to a simpler time and place.
The big difference though, is the processor performance that is available today. Whereas decades ago systems struggled for adequate performance and needed pre-emption and interrupts driving events, today we generally have ample processor performance even in embedded systems to support a simpler approach to the solution.
Summary
Making Asynchronous Software Systems Deterministic is very simple: just make them synchronous.
