Process Control & Real time Systems

Describe the concept of process control in Operating systems?

Process Management

Multiprogramming systems explicitly allow multiple processes to exist at any given time, where only one is using the CPU at any given moment, while the remaining processes are performing I/O or are waiting.

The process manager is of the four major parts of the operating system. It implements the process abstraction. It does this by creating a model for the way the process uses CPU and any system resources. Much of the complexity of the operating system stems from the need for multiple processes to share the hardware at the same time. As a conseuence of this goal, the process manager implements CPU sharing ( called scheduling ), process synchronization mechanisms, and a deadlock strategy. In addition, the process manager implements part of the operating system's protection and security.
Process States

During the lifespan of a process, its execution status may be in one of four states: (associated with each state is usually a queue on which the process resides)

1. Executing: the process is currently running and has control of a CPU
2. Waiting: the process is currently able to run, but must wait until a CPU becomes available
3. Blocked: the process is currently waiting on I/O, either for input to arrive or output to be sent
4. Suspended: the process is currently able to run, but for some reason the OS has not placed the process on the ready queue
5. Ready: the process is in memory, will execute given CPU time
   

Process Control Block (PCB)

If the OS supports multiprogramming, then it needs to keep track of all the processes. For each process, its process control block PCB is used to track the process's execution status, including the following:

• Its current processor register contents.
• Its processor state (if it is blocked or ready).
• Its memory state.
• A pointer to its stack.
• Which resources have been allocated to it.
• Which resources it needs 

Real time Systems /RTOS

Real-Time systems span several domains of computer science. They are defense and space systems, networked multimedia systems, embedded automative electronics etc. In a real-time system the correctness of the system behavior depends not only the logical results of the computations, but also on the physical instant at which these results are produced. A real-time system changes its state as a function of physical time, e.g., a chemical reaction continues to change its state even after its controlling computer system has stopped. Based on this a real-time system can be decomposed into a set of subsystems i.e., the controlled object, the real-time computer system and the human operator. A real-time computer system must react to stimuli from the controlled object (or the operator) within time intervals dictated by its environment. The instant at which a result is produced is called a deadline. If the result has utility even after the deadline has passed, the deadline is classified as soft, otherwise it is firm. If a catastrophe could result if a firm deadline is missed, the deadline is hard. Commands and Control systems, Air traffic control systems are examples for hard real-time systems. On-line transaction systems, airline reservation systems are soft real-time systems. 

Classification Of Real-Time Systems

Real-Time systems can be classified [Kopetz97] from different perspectives. The first two classifications, hard real-time versus soft real-time, and fail-safe versus fail-operational, depend on the characteristics of the application, i.e., on factors outside the computer system. The second three classifications, guaranteed-timeliness versus best-effort, resource-adequate versus resource-inadequate, and event-triggered versus time-triggered, depend on the design and implementation, i.e., on factors inside the computer system. However this paper focuses on the differences between hard and soft real-time classification.

Hard Real-Time versus Soft Real-Time

Tabel 1 shows the major differences between hard and soft real-time systems. The response time requirements of hard real-time systems are in the order of milliseconds or less and can result in a catastrophe if not met. In contrast, the response time requirements of soft real-time systems are higher and not very stringent. In a hard real-time system, the peak-load performance must be predictable and should not violate the predefined deadlines. In a soft real-time system, a degraded operation in a rarely occurring peak load can be tolerated. A hard real-time system must remain synchronous with the state of the environment in all cases. On the otherhand soft real-time systems will slow down their response time if the load is very high. Hard real-time systems are often safety critical. Hard real-time systems have small data files and real-time databases. Temporal accuracy is often the concern here. Soft real-time systems for example, on-line reservation systems have larger databases and require long-term integrity of real-time systems. If an error occurs in a soft real-time system, the computation is rolled back to a previously established checkpoint to initiate a recovery action. In hard real-time systems, roll-back/recovery is of limited use.

Source:  https://users.ece.cmu.edu/~koopman/des_s99/real_time/