
- •Introduction
- •Applications of Real-Time Systems
- •Voltage
- •Figure 7: Conversion of an Analog Signal to a 16 bit Binary Number
- •Figure 11: Schematic Representation of tmr
- •It is relatively simple to design a hardware equipment to be fault-tolerant. The following are two methods that are popularly used to achieve hardware fault-tolerance:
- •Software Fault-Tolerance Techniques
- •Types of Real-Time Tasks
- •Timing Constraints
- •Events in a Real-Time System
- •Figure 16: Delay Constraint Between Two Events el and e2
- •Examples of Different Types of Timing Constraints
- •Figure 19: Classification of Timing Constraints
- •Real-Time Task Scheduling
- •Figure 1: Relative and Absolute Deadlines of a Task
- •Figure 2: Precedence Relation Among Tasks
- •Types of Real-Time Tasks and Their Characteristics
- •Classification of Real-Time Task Scheduling Algorithms
- •Figure 5: An Example Schedule Table for a Cyclic Scheduler
- •Figure 6: Major and Minor Cycles in a Cyclic Scheduler
- •Comparison of Cyclic with Table-Driven Scheduling
- •Hybrid Schedulers
- •Event-driven Scheduling
- •Is edf Really a Dynamic Priority Scheduling Algorithm?
- •Implementation of edf
- •Figure 10: Priority Assignment to Tasks in rma
- •We now illustrate the applicability of the rma schodulability criteria through a few examples.
- •Deadline Monotonic Algorithm (dma)
- •Handling Aperiodic and Sporadic Tasks
- •Dealing With Task Jitter
- •W Good real-time task scheduling algorithms ensure fairness to real-time tasks while scheduling.
- •State whether the following assertions are True or False. Write one or two sentences to justify your choice in each case.
- •Figure 2: Unbounded Priority Inversion
- •Highest Locker Protocol(hlp)
- •Priority Ceiling Protocol (pcp)
- •Comparison of Resource Sharing Protocols
- •Handling Task Dependencies
- •Fault-Tolerant Scheduling of Tasks
- •Clocks in Distributed Real-Time Systems
- •Clock Synchronization
- •Figure 1: Centralized synchronization system
- •Cn Slave clocks
- •Commercial Real-Time Operating Systems
- •Time Services
- •Clock Interrupt Processing
- •Providing High Clock Resolution
- •Figure 2: Use of a Watchdog Tinier
- •Unix as a Real-Time Operating System
- •In Unix, dynamic priority computations cause I/o intensive tasks to migrate to higher and higher priority levels, whereas cpu-intensive tasks are made to seek lower priority levels.
- •Host-Target Approach
- •Preemption Point Approach
- •Self-Host Systems
- •Windows As a Real-Time Operating System
- •Figure 9: Task Priorities in Windows nt
- •Open Software
- •Genesis of posix
- •Overview of posix
- •Real-Time posix Standard
- •Rt Linux
- •7.8 Windows ce
- •Benchmarking Real-Time Systems
- •Figure 13: Task Switching Time Among Equal Priority Tasks
- •Real-Time Communication
- •Figure 2: a Bus Architecture
- •Figure 4: Logical Ring in a Token Bus
- •Soft Real-Time Communication in a lan
- •Figure 6: Priority Arbitration Example
- •Figure 8: Problem in Virtual Time Protocol
- •Figure 9: Structure of a Token in ieee 802.5
- •Figure 10: Frames in the Window-based Protocol
- •Performance Comparison
- •A Basic Service Model
- •Traffic Characterization
- •Figure 16: Constant Bit-Rato Traffic
- •Routing Algorithms
- •Resource Reservation
- •Resource Reservation Protocol (rsvp)
- •Traffic Shaping and Policing
- •Traffic Distortion
- •Traffic Scheduling Disciplines
- •Figure 20: Packet Service in Jittor-edd
- •Differentiated Services
- •Functional Elements of DiffServ Architecture
- •Real Time Databases
- •Isolation: Transactions are executed concurrently as long as they do not interfere in each other’s computations.
- •Real-Time Databases
- •Real-Time Database Application Design Issues
- •Temporal Consistency
- •Concurrency Control in Real-Time Databases
- •It can bo shown that pcp is doadlock froo and single blocking. Rocolloct that single blocking moans that once a transaction starts executing after being blocked, it may not block again.
- •Speculative Concurrency Control
- •Comparison of Concurrency Control Protocols
- •Commercial Real-Time Databases
- •Figure 16: Uniform Priority Assignment to Tasks of Example 15
- •Version 2 cse, iit Kharagpur
Open Software
Before we discuss open software, let us discuss open systems, which has a much wider connotation. An open system is a vendor neutral environment, which allows users to intermix hardware, software, and networking solutions from different vendors. Open systems are based on open standards and are not copy righted, saving users from expensive intellectual property right (IPR) law suits. Open system advocates standard interfaces for similar products; so that users can easily integrate their application with the products supplied by any vendor. This leads to vendor-neutral solutions. The most important goals of open systems are: interoperability and portability. Interoperability means systems from multiple vendors can exchange information among each other. A system is portable if it can be moved from one environment to another without modifications. As part of the open system initiative, open software movement has become popular.
Open software holds out tremendous advantages to both the users as well as system developers. Advantages of open software include the following: It reduces cost of development and time to market a product. It helps increase the availability of add-on software packages. It enhances ease of programming. It facilitates easy integration of separately developed modules. POSIX is an off-shoot of the open software movement.
Open software standards can bo divided into throo categories:
Open Source: Provides portability at the source code level. To run an application on a new platform would require only compilation and linking. ANSI and POSIX are important open source standards.
Open Object: This standard provides portability of unlinked object modules across different platforms. To run an application in a new environment, relinking of the object modules would be required.
Open Binary: This standard provides complete software portability across hardware platforms based on a common binary language structure. An open binary product can be portable at the executable code level. At the moment, no open binary standards exist.
The main goal of POSIX is application portability at the source code level. Before we discuss about the RT- POSIX, let us explore the historical background under which POSIX was developed.
Genesis of posix
Before we discuss the different features of the POSIX standard in the next subsection, let us understand the historical events that led to the development of POSIX. Unix was originally developed by AT&T Bell Labs in the early seventies. Since AT&T was primarily a telecommunication company, it felt that Unix was not commercially important for it. Therefore, it distributed Unix source code free of cost to several universities. UCB (University of California at Berkeley) was one of the earliest recipients of Unix source code.
AT&T later got interested in computers. It realized the potential of Unix and started developing Unix further and came up with Unix V. Meanwhile, UCB had incorporated TCP/IP into Unix through a large DARPA (Defense Advanced Research Project Agency of USA) grant. UCB came up with its own version of Unix and named it as BSD (Berkeley Software Distribution). At this time, the commercial importance of Unix started to grow very rapidly. As a result, many vendors implemented and extended Unix services in different ways: IBM with its AIX, HP with its HP-UX, Sun with its Solaris, Digital with its Ultrix, and SCO with SCO-Unix are some of the prominent examples. Since there were so many variants of Unix, portability of applications across Unix platforms became a problem. It resulted in a situation where a program written on one Unix platform would not run on another Unix platform.
The need for a standard Unix was recognized by all. The first effort towards standardization of Unix was taken by AT&T in the form of its SVID(Systom V Interface Definition). However, BSD and other vendors ignored this initiative. The next initiative was taken under ANSI/IEEE, which yielded POSIX.