Real-time systems form one category of specialized distributed systems named Distributed Real-time systems. Real-time programs(and systems) interact with the external world in a way that involves time. when a stimulus appears ,the system must respond to it in a certain way and before a certain dead line. Many Real-time applications and systems are highly structured much more so than general purpose distributed systems. Distributed Real time systems are needed in large complex applications in which the CPU may have to deal with multiple event streams and when it will become more difficult for one machine to meat all the dead lines and real time constraints. Unlike other Distributed systems ,the Real time Distributed systems can often be structured as a collection of computers connected by a network, some computers are Connected to external devices that produce or accept data or expect to be controlled in real time, and computers have sensors for receiving signals from devices or actuators for sending signals to them.
[...] Suppose that a periodic real-time distributed system has m tasks and N processors to run them on. Let Ci be the CPU time needed by task and let Pi be its period, that is, the time between consecutive interrupts. To be feasible, the utilization of the system, µ, must be related to N by the equation m µ = Σ ( ci pi ) N i For example, if a task is started every 20 msec and runs for 10 msec each time, it uses up 0.5 CPUs. [...]
[...] Real-Time Communication Communication in real-time distributed systems is different from communication in other distributed systems. While high performance is always welcome, predictability and determinism are the real keys to success. In this section we will look at some real-time communication issues, for both LANs and WANs. Achieving predictability in a distributed system means that communication between processors must also be predictable. LAN protocols that are inherently stochastic, such as Ethernet, are unacceptable because they do not provide a known upper bound on transmission time. [...]
[...] Many real-time applications and systems are highly structured, much more so than general-purpose distributed systems. Typically, an external device (possibly a clock) generates a stimulus for the computer, which must then perform certain actions before a deadline. When the required work has been completed, the system becomes idle until the next stimulus arrives . Frequently, the stimulii are periodic, with a stimulus occurring regularly every seconds, such as a computer in a TV set or VCR getting a new frame every 1/60 of a second. [...]
[...] None of the algorithms above are provably optimal in a distributed system, but they can be used as heuristics. Also, none of them takes into account order or mutex constraints, even on a uniprocessor, which makes them less useful in practice than they are in theory. Consequently, many practical systems use static scheduling when enough information is available. Not only can static algorithms take side constraints into account, but they have very low overhead at run time. Static Scheduling Static scheduling is done before the system starts operating. [...]
[...] For example, tasks may need access to shared variables, so these have to be reserved in advance. Often there are scheduling constraints, which we have ignored. Finally, some systems do advance planning during runtime, making them hybrids between static and dynamic. CONCLUSION As time is inherently part of the specification of correctness in some applications and as many large and complex applications involving the external world are inherently Real time, Distributed real time systems are also very important. As these systems have it's own unique characteristics and challenges ( eg. Real time communication [...]
using our reader.