Module IV

Architecture Of Kernel
• The kernel is the core component of an operating system (OS),
serving as the bridge between hardware and software
• It manages system resources, such as CPU, memory, and I/O devices,
and ensures that software processes can effectively utilize these
resources
Architecture of Kernel
• The kernel architecture can be divided into several subsystems, each responsible for
specific tasks:
a. Process Management
• Process Scheduler: Determines which process should run on the CPU at any given time,
using scheduling algorithms (e.g., Round Robin, Priority Scheduling).
• Process Control Block (PCB): Maintains the state of each process, including its ID, status,
priority, and other attributes.
• Inter-Process Communication (IPC): Mechanisms like pipes, message queues, and shared
memory that enable processes to communicate and synchronize with each other.
b. Memory Management
• Memory Allocation: Handles the allocation and deallocation of memory space to
processes.
• Virtual Memory: Allows the system to use more memory than physically available by
swapping data between RAM and disk storage.
• Paging/Segmentation: Techniques used to divide and manage memory, ensuring efficient
c. File System Management: Provides an API for applications to perform
operations like reading, writing, and managing files.
d. Device Management
• I/O Scheduler: Manages the order in which I/O operations are performed,
optimizing performance and resource utilization.
• Interrupt Handlers: Respond to hardware interrupts (signals from devices) and
trigger appropriate actions within the kernel.
e. Security and Access Control
• User Authentication: Ensures that only authorized users can access the system.
• Access Control Lists (ACLs): Define the permissions for each user or process
regarding access to files, directories, and other resources.
• Encryption: Protects data by converting it into a secure format that
unauthorized users cannot easily decode.
 Task
• A task, also referred to as a thread or process, is an independent sequence of execution
within the system. The RTOS manages multiple tasks, ensuring they run concurrently and
meet their timing constraints
• Key Characteristics of Tasks
1.Independence: Each task operates independently of other tasks, with its own context
2.Determinism: In an RTOS, tasks must exhibit deterministic behavior, meaning they execute
within predictable time bounds.
3.Priority: Tasks are typically assigned priorities, which determine the order of execution.
4.Context Switching: The RTOS can switch between tasks rapidly through context switching,
saving the state of the current task and loading the state of the next one
5.Blocking and Synchronization: Tasks may need to wait for resources or events. Blocking
operations cause a task to pause until a condition is met, while synchronization
mechanisms ensure tasks cooperate correctly when accessing shared resources
• Types of Tasks: There are four types of tasks that are being handled
by the real-time operating system classification
1. Periodic Tasks:
• In periodic tasks, tasks are released at regular intervals. A task that
takes place after a fixed interval of time is known as a periodic task
2. Dynamic Tasks
• It is a program that is sequential and invoked by the occurrence of an
event. An event may be generated by an external or internal process
in the system. Dynamic tasks are further classified into two types:
Aperiodic Tasks: If jobs have unpredictable release times a task is
termed an aperiodic task. Tasks falling under this category have soft
deadlines or no deadlines
Sporadic Tasks: They are similar to aperiodic tasks as they also
occur randomly in the system without any specific pattern but the
only thing that differentiates them is they have strict deadlines to
meet.
3. Critical Tasks
• Those tasks in RTOS whose timely executions are critical. If
timelines are missed then it can cause great difficulty. So
meeting the timelines is very crucial under this category of
task
4. Non-critical Tasks
• Real time tasks come under the category of non-critical tasks.
As the name suggests, these tasks are not critical to the
application
Task States:
• Fig shows a task and its state
• Task has state, which includes its status at a given instance in the system
• It can be one of the following state: idle (created), ready, running, blocked
and deleted (finished)
1] Idle (created) state: The task has been created and memory allotted to its
structure. However, it is not ready
2] Ready (Active) State: The created task is ready and is schedulable by the
kernel but not running at present as another higher priority task is scheduled
to run and gets the system resources at this instance
3] Running state: Executing the codes and getting the system resources at this
instance. It will run till it wait for an event or till it gets preempted by another
higher priority task than this one
4] Blocked (waiting) state: Execution of task codes suspends after saving the
needed parameters into its context
5] Deleted (finished) state: The created task has memory deallotted to its
structure. It frees the memory. Task has to be re-created
 Interrupt Service Routine (ISR)
• An Interrupt Service Routine (ISR) is a special function in a microcontroller or
processor that is executed in response to an interrupt
• When an interrupt occurs, the control of the program is transferred to the ISR,
which contains the code necessary to handle the specific event that triggered
the interrupt
• Key Characteristics of an ISR
• Automatic Execution: An ISR is executed automatically in response to an
interrupt, without any explicit call from the main program.
• Short and Fast: ISRs are typically designed to be as short and fast as possible.
This is because while an ISR is executing, other interrupts might be delayed
or missed, and the main program execution is paused.
• Global Interrupt Disable: During the execution of an ISR, the global interrupt
might be disabled to prevent other interrupts from interfering with the
current one
• Context Saving and Restoring: Before executing the ISR, the current state of
the microcontroller (like register contents, program counter) is saved. After
the ISR completes, this context is restored, allowing the main program to
continue from where it left off
• How ISRs Work
1.Interrupt Generation: An interrupt can be generated by various sources, such as external
devices (e.g., timers, sensors), internal events (e.g., timer overflow), or software
2.Interrupt Detection: The microcontroller continuously monitors its interrupt lines or flags.
When an interrupt occurs, the corresponding flag is set.
3.Interrupt Acknowledgment: Once an interrupt is detected, the microcontroller
acknowledges it by temporarily pausing the execution of the main program.
4.Context Saving: The current state of the CPU, including the program counter (which points
to the next instruction to be executed in the main program) and registers, is saved onto the
stack.
5.ISR Execution: The microcontroller then jumps to a specific memory location where the ISR
code is stored and begins executing it.
6.Context Restoration: After the ISR finishes execution, the saved context is restored,
including the program counter, so the main program can resume execution exactly where it
was interrupted.
7.Return from Interrupt: The microcontroller then resumes normal program execution from
the point where the interrupt occurred.
 Semaphore
• A semaphore is used to manage how multiple programs or processes access
shared resources, like memory or files, without causing conflicts
• Imagine you and your friends want to use a single swing in a park. To make
sure only one person uses the swing at a time, you can use a token. Whoever
has the token gets to use the swing, and when they’re done, they pass the
token to the next person.
• Semaphore works like that token. It helps manage the use of resources, like
memory or files, by allowing only a certain number of processes (or programs)
to access the resource at the same time. This prevents conflicts and ensures
smooth operation.
• Types of Semaphores:
1.Binary Semaphore:
• A binary semaphore has two states: "0" (locked) and "1" (unlocked).
• It functions similarly to a mutex (mutual exclusion), where only one task can acquire
the semaphore (lock the resource) at a time.
• When a task takes a binary semaphore, it changes the state to "0". If another task tries
to take the semaphore while it is "0", it will be blocked until the semaphore is released
(state changes to "1").
2.Counting Semaphore:
• A counting semaphore has pool with multiple instances.
• The semaphore is initialized with a count equal to the number of available resources.
• Each time a task takes a semaphore (acquires a resource), the count is decremented.
When the task releases the semaphore (releases the resource), the count is
incremented.
• If the semaphore count reaches zero, tasks attempting to take the semaphore will be
blocked until a resource becomes available (i.e., the count is incremented).
• Working Mechanism:
• Initialization: A semaphore is created and initialized with a value representing
the available resources or an initial state.
• Take (Wait, P): A task attempts to take (or wait on) the semaphore. If the
semaphore's value is greater than zero, the value is decremented, and the task
proceeds. If the value is zero, the task is blocked until the semaphore is
released by another task.
• Give (Signal, V): A task that has finished using the shared resource or
completed its operation signals the semaphore by incrementing its value. If any
tasks were blocked waiting for the semaphore, one of them is unblocked and
allowed to proceed.
• Timeouts: Some RTOS implementations support timeouts, where a task waiting
on a semaphore will be unblocked after a specified time
 Mutex
• A mutex (short for "mutual exclusion") is a synchronization primitive used in
concurrent programming to manage access to shared resources
• When multiple threads or processes need to access a shared resource, a mutex
ensures that only one of them can access the resource at a time, thereby
preventing conflicts and potential data corruption

• Purpose of Mutexes
• Prevent Race Conditions: Race conditions occur when multiple threads or
processes read and write shared data concurrently, leading to unpredictable
results. Mutexes help prevent this by serializing access to the shared resource.
• Ensure Data Integrity: By allowing only one thread or process to access a
critical section of code or a resource at a time, mutexes help maintain the
integrity of data and avoid inconsistencies.
• How Mutexes Work
• Locking and Unlocking: A mutex provides operations to lock and unlock the resource it
protects. When a thread or process locks a mutex, it gains exclusive access to the protected
resource. Other threads or processes that attempt to lock the same mutex are blocked until
the mutex is unlocked.
• Critical Sections: The code that accesses shared resources and requires mutual exclusion is
called a critical section. Mutexes are used to guard these critical sections to ensure that only
one thread or process executes them at any given time.

• Types of Mutexes
• Binary Mutex (or Simple Mutex): This is the most basic form of a mutex, which can be either
locked or unlocked. It is used to provide exclusive access to a resource.
• Recursive Mutex: Allows the same thread to lock the mutex multiple times. This is useful in
cases where a thread may need to acquire the same lock recursively.
• Timed Mutex: Allows a thread to attempt to lock a mutex with a specified timeout period. If
the mutex is not acquired within this time, the attempt fails.
• Error Checking Mutex: Provides error checking capabilities to detect and report errors, such as
attempting to unlock a mutex that the thread does not own.
 Difference between mutex and
semaphore
• Mutex uses a locking mechanism. When a process uses
a resource, it locks the resource, uses it, then releases it
• On the other hand, a semaphore uses a signaling
mechanism using the wait() and signal() methods to
indicate whether a process is releasing or acquiring a
resource
 Mailbox

• Tasks can also communicate by sending messages via mailboxes

• A mailbox is a special memory location that one or more tasks can use to
transfer data
• In RTOS, a mailbox is a communication mechanism used for inter-task or inter-
process communication. It allows tasks (or threads) to send and receive
messages in a way that ensures reliable and orderly communication
• The tasks rely on the kernel to allow them to
write to the mailbox via a post operation
Or read from it via a pend operation
A mailbox can only contain one message
• The mail that is passed via the mailbox can be
a single piece of data,
or a pointer to a data structure
• Purpose of Mailboxes

• Data Exchange: They facilitate the exchange of messages or data between

tasks or between tasks and ISRs
• Decoupling: They decouple the sender and receiver tasks, allowing them to
operate independently without needing to synchronize their execution
directly.
• Asynchronous Communication: They support asynchronous message
passing, enabling tasks to send messages without waiting for the receiver to
be ready
• Working of a Mailboxes
• Structure: A mailbox typically consists of a queue where messages are stored
until they are retrieved by the receiving task
• Send Operation: When a task sends a message to a mailbox, the message is
placed in the queue. If the mailbox is full, the sending task may be blocked
until there is space available, or it may return an error or status code
indicating that the message could not be sent.
• Receive Operation: When a task receives a message from a mailbox, it
retrieves the message from the queue. If the mailbox is empty, the receiving
task may be blocked until a message is available, or it may return an error or
status code indicating that no message was available.
• Mailbox Types

• Standard Mailbox: A simple mailbox that provides basic functionality for

sending and receiving messages. It is suitable for many common
communication needs.
• Priority Mailbox: In some RTOS implementations, mailboxes support priority-
based message handling. Messages can be assigned priorities, and the
mailbox processes higher-priority messages before lower-priority ones.
• Message Queue: This is often used interchangeably with mailboxes in some
RTOS environments. It supports message queuing with additional features
like message timeouts and message filtering.
 Message Queues
• A Message Queue is an inter-process communication (IPC) mechanism that
allows tasks (threads) to send and receive messages, enabling
synchronization and data exchange between different tasks or between tasks
and interrupt service routines (ISRs)
• Message queues are particularly useful in systems where tasks need to
communicate asynchronously (means interaction without real-time
conversation — replies can be delayed), share data, or signal events without
tightly coupling (i.e strong dependency between internal states,
data and functions) the tasks to each other.
• Components of a Message Queue
1.Message: A discrete unit of data that is sent from one task to another through
the message queue. Messages can be of fixed or variable size, depending on the
RTOS implementation. The message typically contains data relevant to the
receiving task, such as sensor readings, control commands, or event
notifications.
2.Queue: A data structure that holds messages. It operates in a FIFO (First-In-First-
Out) manner, meaning the first message sent to the queue is the first message
received. Some RTOSs might support priority-based message queues where
messages can be sorted based on priority levels.
3.Sender (Producer): The task or ISR that sends a message to the queue. The
sender places a message in the queue when it has data to communicate or when
it needs to notify another task of an event.
4.Receiver (Consumer): The task that receives messages from the queue. The
receiver retrieves and processes messages, which might involve acting on the
data or further communicating with other tasks.
• Working of Message Queue
1.Creating a Message Queue: Before tasks can communicate using a message queue, the queue must
be created. During creation, parameters like the maximum number of messages (queue depth) and
the size of each message are defined. The RTOS provides API functions for creating and managing
message queues.
2.Sending Messages: When a task or ISR sends a message, the message is copied into the queue. If the
queue is full (i.e., it has reached its maximum capacity), the behavior depends on the RTOS
configuration:
Block: The sender can block (wait) until space is available in the queue
Timeout: The sender can wait for a specified period for space to become available
Immediate Return: The sender can immediately return with an error or status indicating that the
queue is full
3. Receiving Messages: A task can receive messages from the queue in a blocking or non-blocking
manner:
Blocking Receive: The task waits until a message is available in the queue. This is useful when the task
has no other work to do until it receives new data
Non-blocking Receive: The task checks the queue for a message but does not block if the queue is
empty. Instead, it can return immediately with a status indicating no message was available. Once a
message is received, it is typically removed from the queue. The receiving task then processes the
message as needed.
 Pipes
• Pipes in a RTOS are an IPC mechanism that allows data to be transferred
between tasks, or between a task and an interrupt service routine ISR, in a
unidirectional or bidirectional manner
• They are typically used to send streams of data from one context to another,
facilitating synchronization and data exchange in real-time systems.
• Key Concepts of Pipes in RTOS
1.Pipe: A pipe is essentially a buffered (Buffering allows data to be stored temporarily,
enabling the sender and receiver to operate without needing to be synchronized)
communication channel that connects two or more tasks, allowing them to
pass data back and forth
• Data written into the pipe by one task can be read by another task, making
pipes a useful tool for tasks that need to process or respond to data
generated by other tasks or hardware events
2. Unidirectional vs. Bidirectional:
• Unidirectional Pipe: Data flows in only one direction—from a sender to a receiver. This is
common in producer-consumer scenarios where one task generates data and another
processes it.
• Bidirectional Pipe: Data can flow in both directions, allowing two tasks to communicate
back and forth through the same pipe
3. Buffer: The pipe typically includes a buffer that temporarily stores the data being
transferred. The size of this buffer determines how much data can be written to the pipe
before it must be read by the receiving task. This buffering allows the sender and receiver to
operate asynchronously, decoupling (separating or making independent the execution times of the sender and receiver)
their execution times
4. Blocking and Non-blocking Operations:
• Blocking Write/Read: When a task writes to or reads from a pipe, it may block (wait) if the
pipe is full (for writing) or empty (for reading). The task resumes when space becomes
available in the pipe (for writing) or when data is available (for reading).
• Non-blocking Write/Read: In non-blocking mode, the task does not wait if the pipe is full or
empty. Instead, it immediately returns a status indicating that the operation could not be
complete
• How Pipes Work
1.Creating a Pipe:
• Before using a pipe, it must be created and initialized. The RTOS provides API functions to create pipes,
specifying parameters like buffer size, pipe direction (unidirectional or bidirectional), and any other
configuration options
2. Writing to a Pipe:
• A task or ISR can write data into the pipe. The data is placed in the pipe's buffer, and the RTOS
manages the movement of this data to ensure it can be read by the receiving task
• If the pipe’s buffer is full, the writing task may block until space is available (in blocking mode) or
return immediately with an error status (in non-blocking mode)
3. Reading from a Pipe:
• The receiving task reads data from the pipe's buffer. The RTOS ensures that data is transferred
correctly and that the pipe is synchronized, so data integrity is maintained.
• If the pipe is empty, the reading task may block until new data is available (in blocking mode) or return
immediately with a status indicating that no data is available (in non-blocking mode)
4. Pipe as a Stream:
• Unlike message queues, which typically handle discrete messages, pipes are
often used for streaming data. This makes them suitable for applications like
continuous sensor data collection, where data arrives in a steady stream
rather than in discrete packets
5. Closing a Pipe:
• Pipes can be closed when no longer needed. Closing a pipe typically involves
freeing up the resources associated with it, such as the buffer and any
control structures
 Signals
• Signals are a lightweight IPC mechanism used to notify tasks of events or to trigger specific
actions. They are similar to event flags and semaphores but are generally simpler and faster,
making them well-suited for quick notifications and task synchronization.
• Key Concepts of Signals in RTOS
1.Signal: A signal is an asynchronous notification sent to a task to inform it that a particular
event has occurred or that it should perform a specific action. Signals are often represented
as bits within a signal register where each bit corresponds to a different signal.
2.Signal Register/Set: A signal register or signal set is a data structure that holds multiple
signals, typically as individual bits. Each bit in the register represents a specific signal. Tasks
can wait for specific signals to be set, allowing them to synchronize with other tasks or
events.
3.Task Notification: When a signal is sent to a task, it notifies the task that a particular
condition has been met. The task can then take appropriate action based on the signal, such
as executing a particular function, handling an event, or resuming from a waiting state.
4.Synchronization: Signals are used to synchronize tasks by ensuring that one task waits for a
specific event or condition before proceeding
• Working of Signals
1.Creating and Initializing Signals: Signals are usually predefined within the RTOS, and tasks can register
to wait for or handle specific signals. Unlike message queues or semaphores, signals do not require
explicit creation or initialization—they are often a built-in feature of the task management system
2. Sending Signals: A signal can be sent by a task or an ISR to another task. This is typically done by setting
the corresponding bit in the task's signal register. Sending a signal is a fast operation, as it usually involves
only setting a bit in memory.
3. Waiting for Signals: A task can wait for one or more signals before continuing its execution. The task
specifies which signals it is interested in by providing a bitmask that indicates the relevant signal bits
• The task can wait in different modes:
 Wait for any signal: The task continues when any of the specified signals are set
 Wait for all signals: The task continues only when all specified signals are set
 Timeout-based wait: The task waits for the signals to be set but will continue after a specified timeout if
the signals do not occur.
4. Clearing Signals: Once a task receives and processes a signal, the signal bit may be cleared to
acknowledge the event and prevent it from being processed multiple times. The RTOS might automatically
clear the signal bit after the task is notified, or the task may need to clear it manually
 Timers
• Timers in a RTOS are crucial components used to measure time intervals,
schedule tasks, and handle time-based events
• They provide a way to execute code after a specific time delay, periodically
trigger tasks, or perform time-based operations like timeout management
• Timers are an essential feature in embedded and real-time systems, where
precise timing and deterministic behavior are critical.
• Key Concepts of Timers in RTOS
1. Timer:
1. A timer is a software or hardware component that counts down from a specified value to zero, generating an event when
the countdown completes. In an RTOS, timers are typically used to trigger tasks or functions after a delay or at regular
intervals.
2. Software vs. Hardware Timers:
1. Software Timers: Managed by the RTOS, these timers rely on periodic interrupts from a hardware timer. Software timers
are flexible and can be created, started, stopped, and reset dynamically.
2. Hardware Timers: These are physical components within the microcontroller that generate precise timing events. They are
more accurate than software timers and are often used for critical timing functions such as generating PWM signals,
counting events, or producing precise delays.
3. One-Shot vs. Periodic Timers:
1. One-Shot Timer: A one-shot timer triggers an event or task once after a specified delay and then stops. It’s useful for
operations that need to occur a single time after a delay, such as a timeout for a communication operation.
2. Periodic Timer: A periodic timer triggers an event or task at regular intervals. It restarts itself automatically after each
interval, making it ideal for tasks that need to run repeatedly, such as updating a display or polling a sensor.
4. Tick Rate:
1. The tick rate is the frequency at which the RTOS scheduler's tick interrupt occurs. It is typically derived from a hardware
timer. The tick rate determines the granularity of software timers, meaning how accurately they can measure time
intervals. A higher tick rate allows for finer timing resolution but increases overhead.
5. Callback Function:
1. Timers in an RTOS often trigger a callback function when they expire. This function contains the code that should be
executed when the timer reaches zero. The callback function is typically executed in the context of a timer task or interrupt,
depending on the RTOS implementation.
• Working of Timers in an RTOS
1.Creating a Timer:
• In an RTOS, timers are created using API functions provided by the RTOS.
When creating a timer, parameters such as the delay, timer type (one-shot or
periodic), and the callback function are specified
• For example, in FreeRTOS, the ‘xTimerCreate()’ function is used to create a
timer, where you specify the timer name, period, whether it’s auto-reload
(periodic), and the callback function.
2. Starting a Timer:
• Once a timer is created, it needs to be started to begin the countdown
• Starting a timer typically involves enabling it and setting it to count down
from the specified time period
• In the case of software timers, starting the timer involves registering it with
the RTOS scheduler so that it gets decremented with each tick.
3. Stopping and Resetting a Timer:
• A timer can be stopped before it expires if the event it was intended to trigger is no
longer needed. This is useful in scenarios where the condition that the timer was
waiting on is met prematurely.
• Resetting a timer means restarting the countdown from the original time value. This
can be done if you want to extend the delay period or if the event that the timer was
waiting for is still pending.
4. Timer Expiry and Callback Execution:
• When a timer expires (i.e., its countdown reaches zero), the RTOS executes the
associated callback function. This function is where the timed action is performed,
such as sending a signal to a task, toggling an LED, or handling a timeout event.
• Depending on the RTOS, the callback function might run in the context of the timer
task or in the context of an interrupt, so it must be designed to execute quickly and
avoid blocking operations
5. Deleting a Timer: Once a timer is no longer needed, it can be deleted to free up
resources. Deleting a timer involves unregistering it from the RTOS and deallocating any
memory or resources associated with it.
 Priority Inversion Problem
• Priority Inversion is a problematic scenario in real-time and multitasking
systems where a higher-priority task is indirectly preempted by a lower-
priority task, leading to potential delays in the execution of the higher-priority
task
• This situation can be particularly critical in RTOS where meeting timing
deadlines is crucial
• Key Concepts in Priority Inversion
1.Task Priority: In an RTOS, tasks are typically assigned priorities. Higher-
priority tasks are intended to preempt lower-priority tasks to ensure that
time-sensitive operations are completed promptly.
2.Resource Sharing: Tasks often share resources, such as memory, hardware
peripherals, or data structures. To avoid conflicts when accessing shared
resources, tasks use synchronization mechanisms like mutexes or
semaphores
3.Preemption: In a preemptive RTOS, when a higher-priority task becomes
ready to run, it preempts the currently running lower-priority task. This
ensures that high-priority tasks get CPU time as soon as they need it.
• The Priority Inversion Scenario: Priority inversion occurs when a higher-priority task is forced to wait for a
lower-priority task to release a resource, while another task with an even lower priority preempts the one
holding the resource. Here’s how it typically unfolds:
1. Scenario Setup: Imagine three tasks with different priorities:
1. Task A: High priority.
2. Task B: Medium priority.
3. Task C: Low priority.
2. Initial Condition: Task C acquires a resource (e.g., a mutex) that Task A will eventually need. Task C starts
executing and holds onto the resource.
3. Task A Becomes Ready: Task A becomes ready to execute and preempts Task C, as Task A has a higher priority.
However, Task A immediately tries to acquire the same resource that Task C is holding, forcing Task A to block
and wait for the resource to be released.
4. Task B Becomes Ready: Before Task C can release the resource, Task B (medium priority) becomes ready to
execute. Since Task B has a higher priority than Task C but lower than Task A, it preempts Task C. However,
Task B does not need the resource that Task A and Task C are contending for.
5. Priority Inversion: Now, Task C (low priority) cannot run to release the resource because Task B (medium
priority) is running. Task A (high priority) is blocked, waiting for Task C to release the resource, but Task C is
effectively prevented from running due to Task B’s preemption. Task A, which has the highest priority, is
indirectly delayed by the medium-priority Task B.
6. Impact: This delay is called priority inversion because the high-priority task (Task A) is forced to wait for a
lower-priority task (Task C), which in turn is prevented from running by an intermediate-priority task (Task B).
This inversion can cause significant issues, particularly in real-time systems where meeting deadlines is critical.
• Consequences of Priority Inversion
1.Missed Deadlines: In real-time systems, tasks often have strict deadlines.
Priority inversion can lead to missed deadlines for high-priority tasks, which
can result in system failures, degraded performance, or safety hazards.
2.Reduced System Responsiveness: The system’s overall responsiveness can
be significantly reduced if priority inversion occurs frequently or if the
duration of the inversion is long. High-priority tasks may be delayed
unnecessarily, leading to a sluggish or unresponsive system.
3.Unpredictable Behavior: Priority inversion introduces unpredictability into
the system, making it difficult to guarantee that high-priority tasks will meet
their timing constraints. This unpredictability is particularly problematic in
systems that require deterministic behavior
• Solutions to the Priority Inversion Problem: Several strategies have been developed to mitigate or prevent priority
inversion:
1. Priority Inheritance Protocol:
1. When a low-priority task (e.g., Task C) holding a resource is preempted by a higher-priority task (e.g., Task A) that requires the
same resource, the low-priority task temporarily inherits the priority of the higher-priority task. This prevents an intermediate-
priority task (e.g., Task B) from preempting the low-priority task. Once the low-priority task releases the resource, it reverts to its
original priority.
2. Example: In the scenario above, Task C would inherit Task A’s priority, preventing Task B from preempting it. Task C would run to
completion, release the resource, and allow Task A to proceed.
2. Priority Ceiling Protocol:
1. This protocol assigns a ceiling priority to each resource, which is the highest priority of any task that may lock the resource. When a
task locks a resource, its priority is raised to the ceiling priority. This prevents any higher-priority tasks from preempting it until the
resource is released, effectively avoiding priority inversion.
2. Example: If Task C locks a resource with a ceiling priority equal to Task A’s priority, Task B cannot preempt Task C while it holds the
resource. This ensures that Task C can complete its work and release the resource for Task A.
3. Timeouts and Deadlock Detection:
1. Implementing timeouts for resource acquisition can help detect and resolve priority inversion situations. If a high-priority task
waits too long for a resource, the system can take corrective actions, such as aborting the lower-priority task, escalating priorities,
or signaling an error condition.
2. Example: Task A could have a timeout on its wait for the resource. If the timeout occurs, the system might either forcibly release
the resource from Task C or raise an alert for corrective action.
4. Avoiding Shared Resources:
1. One way to prevent priority inversion is to design the system such that tasks avoid sharing resources or minimize the use of shared
resources. This reduces the likelihood of tasks blocking each other and eliminates potential inversion scenarios.
2. Example: By redesigning the system so that Task C doesn’t need to lock the resource that Task A requires, the priority inversion
scenario can be avoided entirely.