December 21st, 2017 by
The synchronous programming model is based on the zero time computation idea. It assumes that every synchronous program activity, including communication, consumes zero time which is referred to as soft-time. A synchronous program model is executed in the computational or physical context process that generates stimulus events for the program. That said, a synchronous program computes output instantaneously based on the program’s input and state of control in a bid to execute events in zero time. The program can either be deterministic or reactive. A deterministic synchronous program computes one reaction at most for an event and control state. On the other hand, if termination occurs a reactive program computes at least one reaction for an event and control state.
Synchronous programming is referred to as synchronous reactive programming due to its deterministic and instantaneous reactions to its stimulus. Hence, the compiler or programmer must implement reactivity. But because most synchronous programming languages contain cyclic language constructs, programmers must prove that finite fixed points exist. They represent the absence of infinite cycles. Based on the control state representation, proving reactivity can be complex in languages like Esterel that have explicit control flow and less difficult among dataflow languages like Lustre.
Synchronous and reactive programs run at their context’s speed and the output for deterministic programs are determined by their context. From the physical context perspective, the deterministic and reactive program’s behavior should be perfect; program and context are synchronous. Implementation of a synchronous model approximates synchrony through computing event reactions before another event is launched. However, the time taken to compute a reaction may vary. Therefore, synchronous program compliers implement code generation and prove synchrony and reactivity.
The typical discipline of real-time computing is based on the scheduled computation concept. A scheduled program is made up of threads, tasks, and processes and a scheduler defines the scheduled program parts that should run at certain times. Unlike in the synchronous model, the scheduled model does not abstract soft-time. However, it varies depending on the scheduling scheme, performance, and utilization. Soft-time under the scheduled model is controlled by real-time deadlines. The time required to complete a scheduled computation varies based on the implementation mode. A scheduled program’s complier only implements the functionality and not the scheduling left on the runtime system; that is, an RTOS scheduler.
The ability for a program to meet deadlines under this model must be outlined with the used scheduling scheme used in the RTOS. The adherence to deadlines depict the scheduled model as a real-time computing model. Hard real-time deadlines should be met despite the circumstances whereas soft real-time deadlines can sometimes compete after the allocated deadline resulting in acceptable but slightly degraded system performance. Soft real-time applications include; audio and video processing while hard real-time deadlines are applied in embedded control and process control areas such as; missions and safety-critical environments.
The timed model principle works under the notion that communication and computation takes a fixed and certain amount of time; in the timed model, soft-time is equivalent to real-time. Meaning that computation must complete exactly at its specified time. A timed programmer specifies the amount of real-time it requires to compute an output assuming there is enough soft-time; timed programs are time safe. However, time safety is determined by performance, scheduling scheme, and utilization. The compiler evaluates time safety to determine whether the available soft-time is adequate and if not, it rejects the scheduled programs.
But, checking time safety may be challenging because it requires analysis of execution time and scheduled testing. Programs may not always be feasible at compile time. However, if a timed program is due, the program introduces runtime exception, and if it concludes earlier than expected, its release is delayed until its specified real-time elapses. The closer a timed program output implementation is to its specified completion time, the better the implementation estimates the time model. A timed program runs under the computational and physical process context. As such, timed model is ideal for embedded control systems that require precise time predictability that is; specific, low jitter output and input.
The synchronous model is ideal for use in value deterministic real-time programs for safety-critical and mission applications. The scheduled model relies on tools and experience from non-real-time applications and is widely utilized in practice. The timed model is ideal for development of time and value deterministic real-time programs but is mainly applied in the embedded control systems context. Synchronous and scheduled models are more general as compared to timed model. The two models support development of time and value deterministic real-time programs. However, timed model restrictions can be exploited by optimizing code generation of time and value deterministic real-time programs.