
- •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
Speculative Concurrency Control
Speculative Concurrency Control (SCC) protocol tries to overcome a major weakness of the OCC protocols. Recollect that OCC protocols ignore the occurrence of conflict between two transactions until the validation phase of one of them. At this time, it may already have become too late to correct the problem by restarting one of the transactions, especially if the transactions have tight deadlines. To overcome this problem, in SCC, conflicts are checked at every read and write operations. Whenever a conflict is detected, a new version (called the shadow version) of each of the conflicting transactions is initiated. The primary version executes as any transaction would execute under an OCC protocol, ignoring the conflicts that develop. Meanwhile, the shadow version executes as any transaction would do under a pessimistic protocol — subjected to locking and restarts. The idea is to always keep a clean version (a version without any conflicts) in case it is ever needed. This should help in meeting the deadlines of tasks with tight deadlines. When a shadow reaches a point of conflict, it blocks as any transaction under a pessimistic protocol. When the primary version commits, any shadow associated with it is discarded. In addition, any shadow whose serializability depends on the discarded shadows is also discarded. However, when the primary transaction aborts, the shadow starts off executing under OCC as the new primary.
As in the OCC protocols, in SCC protocol also all updates made by a transaction are made on local copies and therefore are not visible until the transaction commits.
Comparison of Concurrency Control Protocols
Before we discuss the relative performance of the different categories of protocols, we highlight some aspects of concurrency control protocols that have significant bearings on their performance. This would help us understand the results obtained from experiments in proper perspective. Locking-based algorithms tend to reduce the degree of concurrent execution of transactions, as they construct serializable schedules. On the other hand, optimistic approaches attempt to increase parallelism to its maximum, but they prune some of the transactions in order to satisfy serializability. In 2PL-HP, a transaction could be restarted by, or wait for another transaction that will be aborted later. Such restarts and/or waits cause performance degradation.
Unlike 2PL-HP, in optimistic approaches when incorporating broadcast commit schemes (OCC-BC), only validating transactions can cause restart of other transactions. Since all validating transactions are guaranteed commitment at completion, all restarts generated by such optimistic protocols are useful [4]. Further, the OCC protocols have the advantage of being non-blocking and free from deadlocks — a very desirable feature in real-time applications.
Performance study results for the different categories of concurrency control protocols are shown in Fig. 7.1. As can be intuitively expected, at zero contention, all the three types of protocols result in identical performance. From Fig. 7.1 it can be seen that at low conflicts OCC outperforms pessimistic protocols. However, pessimistic protocols perform better as the load (and therefore the conflicts) become higher. On the other hand, SCC performs better compared to both OCC and pessimistic protocols, when transactions have tight deadlines and the load is moderate.