A fault-tolerant resource locking protocol for multiprocessor real-time systems

This paper presents the first fault-tolerant resource locking protocol for multiprocessor real-time systems. Resource locking protocols control access to shared resources in real-time systems. Most of the previous studies in resource locking protocols have focused on decreasing blocking time and resource conflicts. The use of such protocols in multiprocessor safety-critical real-time systems necessitates fault tolerance in the design of these systems. However, in research focused on multiprocessor real-time systems, fault tolerance has received low attention in resource allocation studies. In addition, many solutions proposed to improve the reliability in real-time scheduling ignored resource models in their task model. This paper proposes a novel fault-tolerant resource locking protocol, called FTPIA-NPCS, which considers transient faults in shared resources. FTPIA-NPCS proposes a checkpointing-based fault-tolerant mechanism to recover from errors caused by transient faults. In this mechanism, a checkpoint is taken from the tasks, before each resource allocation. In addition to providing fault tolerance, FTPIA-NPCS solves the problem of priority inversion in NPCS protocol for periodic tasks with hard deadlines. The simulation results demonstrate that FTPIA-NPCS tolerates at least one transient fault in resources for each execution of the periodic tasks with 15% blocking time overhead in comparison to its non-fault-tolerant configuration, called PIA-NPCS. Furthermore, the blocking time of higher-priority tasks is minimized in com-parison to PIA-NPCS. An analytical evaluation of the protocol supports the simulation results.

Automated summary

This paper presents the first fault-tolerant resource locking protocol for multiprocessor real-time systems. The protocol considers transient faults in shared resources and proposes a checkpointing-based fault-tolerant mechanism. It also solves the problem of priority inversion in periodic tasks. Simulation results show that the protocol can tolerate at least one transient fault with a 15% blocking time overhead compared to its non-fault-tolerant configuration.