16EE505 – MICROCONTROLLER AND EMBEDDED SYSTEMS UNIT - 5

Session 6 – SLO 1

5.6 DEADLOCK

Concept of Deadlock

Potential for deadlocks exist in a system in which the underlying RTOS permits resource
sharing among multiple threads of execution. Deadlock occurs when the following four
conditions are present: Mutual exclusion - A resource can be accessed by only one task at a
time, i.e., exclusive access mode

Deadlock in Embedded System

In an operating system, a deadlock occurs when a process or thread enters a waiting state
because a requested system resource is held by another waiting process, which in turn is
waiting for another resource held by another waiting process.

Deadlock in Operating System with Example

A deadlock is a situation in which two computer programs sharing the same resource are
effectively preventing each other from accessing the resource, resulting in both programs
ceasing to function. The earliest computer operating systems ran only one program at a time.

When Can A Deadlock Occur?

A lock occurs when multiple processes try to access the same resource at the same time. One
process loses out and must wait for the other to finish. A deadlock occurs when the waiting
process is still holding on to another resource that the first needs before it can finish.

Deadlock and Its Prevention

Deadlock Prevention: In a computer system deadlocks arise when members of a group of

processes which hold resources are blocked indefinitely from access to resources held by
other processes within the group.

Starvation in Deadlock

Starvation and Deadlock: Starvation occurs when one or more threads in your program are
blocked from gaining access to a resource and, as a result, cannot make progress. Deadlock,
the ultimate form of starvation, occurs when two or more threads are waiting on a condition
that cannot be satisfied.

Deadlock Condition

Deadlock is a situation where a set of processes are blocked because each process is holding a
resource and waiting for another resource acquired by some other process. ... Similar
16EE505 – MICROCONTROLLER AND EMBEDDED SYSTEMS UNIT - 5

situation occurs in operating systems when there are two or more processes hold some
resources and wait for resources held by other(s).

Four Conditions That Create Deadlock

mutual exclusion. The resources involved must be unshareable; otherwise,

the processes would not be prevented from using the resource when necessary.
hold and wait or partial allocation. ...
no pre-emption. ...
resource waiting or circular wait

Deadlock Key

A dead bolt, deadbolt or dead lock is a locking mechanism distinct from a spring bolt lock
because a deadbolt cannot be moved to the open position except by rotating the key. ... A
deadbolt can therefore make a door more resistant to entry without the correct key

9.10 DISABLING AND ENABLING FUNCTIONS

A process or ISR ca The instructions in a running process, thread or ISR should not interrupt
till other proccess or isr cabbe permitted to pre-empt the running process. Following are the
ways:

9.10.1 Disabling and Enabling Interrupts

A program may consist of interrupt-service routines, signal handlers, exceptlonal handlers,

ISTs and processes (tasks or threads). Disabling interrupts enables a process or ISR run
uninterrupted. OS scheduler and interrupt-handling mechanisms disable the running of any
other process or ISR. Enabling interrupts enables a process, or ISR interrupted from an
interrupt source or OS can block the process, and higher priority process or ISR can run.

Disabling at the start and enabling at end of codes in a task or ISR section lets the critical
instructions run without any diversion to any routine. Pre-emption and diversion to no other
process or ISR is permitted in between.

LOCK and UNLOCK functions:

When the lock ( ) function executes, it disables the OS scheduler. The OS does not preem t
the current process, and does not start any other processor, task or thread. OS sched P other
process. OS interrupt-servicing mechanism remains active.

Executing lock ( ’) at the start of a task section codes and executing unlock () at end of codes
in a task section lets the critical instructions in a process run without any diversion to another
process but an interrupt source can preempt the running critical section codes

i. Mutex Lock
16EE505 – MICROCONTROLLER AND EMBEDDED SYSTEMS UNIT - 5

Aprocessor using a mutex locks only the running of other critical section of other task, which
is sharing the same mutex. The mutex locks other processes at the start and unlock at end of
codes in a task section, and lets the iii-between critical instructions run without diversion to
process, task or thread with which it is sharing the same mutex so that both processes run
mutually exclusively that section of code which lies between mutex pend and post functions.

‘2: Spin lock

A resource of high priority should not lock the other processes by blocking an already
running task in the following situation. Suppose a task is running and a little time is left for
its completion. The running time left for it is less compared to the time that would be taken in
blocking it and context switching. There is an innovative concept of spin locking in Java and
certain OS schedulers. A spin lock is a powerful tool in the situation described above. A spin
lock when executed sets a lock dag at the OS. The process continues execution while lock
flag is set till spin unlock ( ) function executes. The unlock flag resets at OS scheduler.
Advantage of spin lock over use of mutex lock or scheduler lock is that it does not have any
overhead of IPC functions and context switching.

An application of spin lock is that the codes can be written first spin lock for a time-interval t,
then for (t «dt), then (1 ... 2dr), and so on. When this time interval spin downs to 0, the task
that requested the lock of the processor now unlocks the running task and blocks it from
further running. The request is now granted. Thus, the application as above does not let a
running task be blocked instantly, but first successively tries decreasing the trial periods
before finally blocking a task.

9.11 ] SHARED DATA PROBLEM

Problem of Sharing Data by Multiple Tasks and InterruptServnce Routines:

The shared data problem can be explained as follows. Assume that several functions (or lSRs
or tasks) share a variable. Let us assume that at an instant, the value of that variable operates
and during the operations on it, only a part of the operation is completed and a part remains
incomplete. At that moment, let us assume that there is an interrupt or OS scheduler transfer
the control to other process. Now, assume that there is another function. It also shares the
same variable. The value of the variable may differ from the one expexted if the earlier
operation had been completed. the incomplete operation part can occur

9.11.2 Shared Data Problem Solutions

One solution is the use of atomic operation for solving the shared data problem. The
following are the steps that, if used together, almost eliminate a likely bug in the program due
to the shared data problem

I. Use modifier volatile with a declaration for a variable that returns from the interrupt. This
declaration warns the compiler that certain variables can modify because the ISR does not
consider the fact that the variable is also shared with a calling function.
16EE505 – MICROCONTROLLER AND EMBEDDED SYSTEMS UNIT - 5

2. Use reentrant functions with atomic instructions in that part of a function that needs its
complete execution before it can be interrupted. This part is called the critical section.

3. Put a shared variable in a circular queue. A process, task or thread that requires the value
of this variable always deletes (takes) it from the queue front, and another function, which
inserts (writes) the value of this variable, always does so at the queue back. Now a problem
can occur in case there are a large number of functions that send the value into and get the
value from the queue, and the queue size may be insufficient.

4. Disable the interrupts before a critical section starts executing and enable the interrupts on
its completion. It is a powerful but drastic option. An interrupt, even if it is of higher priority
than the present critical function, gets disabled. Advantage of it is that the semaphore
functions have greater computational overhead than disabling of the interrupt. The difliculty
with this option is that it increases in the interrupt-latency period for all the tasks. The latency
increases by the time taken in executing the codes of the section. A deadline may be missed
for an interrupt service by that task which does not share the critical section or the resource.

5, Lock the OS scheduling mechanism before a critical section starts executing and unlock at
its end. It is a powerful but drastic option. A process even if of higher priority and not sharing
the same data as running process critical function, gets locked. The advantage of it is that it
does not increase the interrupt-latency period for the tasks.

6, Mutex semaphore is an alternative to disabling interrupts and locking scheduler: The

advantage of it is that it does not increase the interrupt-latency period as well as higher
priority processes, which do not share the data with running process critical function.

AsoftWare designer must utilise the various steps optimally suited to solve the problem.

9.11.3 Priority Inversion Problem and Priority Inheritance

Let the priorities of tasks be in an order such that task I is of the highest priority, task J is of a
lower, and task K of the lowest priority. Assume that only tasks I and K share the data and J
does not share data with K. Also let tasks I and K alone share a semaphore and not J. Why do
only a few tasks share a semaphore? Can’t all share a semaphore? The reason is that the
worst-case latency becomes too high and may exceed the deadline if all tasks are blocked
when one task takes a semaphore. The worstcase latency will be small only if the time taken
by the tasks that share the resources is relevant. Now consider the following situation.

At an instant to, suppose task K takes a semaphore, it does not block task J and blocks task I.
This happens because only tasks I and K share the data and J does not Consider the problem
that now arises on selective sharing between K and I. At next instant t1, let task K become
ready first on an interrupt. Now, assume that at next instant t2, task I becomes ready on an
interrupt. At this instant, K is in the critical section. Therefore, task I cannot start at this
instant due to K being in the critical region. Now, if at next instant t3, some action (event)
causes the unblock higher than K priority task J to run. Running task J does not allow after
instant t3, the highest priority task I to run because K is not running, and therefore K can’t
release the semaphore that it shares with I. Further, the design of task .1, may be such that
16EE505 – MICROCONTROLLER AND EMBEDDED SYSTEMS UNIT - 5

even when the semaphore is released by task K, it may not let I run. {J runs the codes as if it
is in critical section all the time] The J action is now as if J has higher priority than I. This is
because K, after entering the critical section and taking the semaphore when letting J run. did
not share the priority information about I~--that task I is of higher priority than J. The priority
information of another higher-priority task I should have also been inherited by K
temporarily, if K Waits for I butJ does not and J runs when K has still not iinished the critical
section codes. This did not happen because the given OS design was such that it didn’t
provide for temporary priority inheritance in such situations.

The above situation is also called a priority inversion problem. An OS must provide for a
solution for the priority inversion problem. Some OSs provide for priority inheritance in these
situations and thus the priority inheritance problem does not occur when using them.

A mutex should be a mutually exclusive Boolean function, by using which the critical section
is Promoted from interruption in such a way that the problem of priority inversion does not
arise, Mutcx is automatically provided in certain 085 so that it the priority inversion safe and
problem does not arise,

9.11.4 Deadlock Situations

Consider another problem. Assume the following situation.

1. Let the priorities of tasks be such that task H is of highest priority. Then task 1 has a lower
priority and task J has the lowest.

2. There are two semaphores, Sem TokI and Sem T0k2. This is because the tasks I and H
have a shared resource through Sem TokI only. Tasks I and .1 have two shared resources
through two semaphores, SemTokI and SemTokZ.

3. Let J interrupt at an instant to and first take both the semaphores Sem Tokl and SemTokZ
and run.

Assume that at a next instant t1, being now of a higher priority, the task H interrupts the task
I and} after it takes the semaphore SemTokI, and thus blocks both I and J. In between the
time interval to and ti, the SemTokI was released but SemTok2 was not released during the
run of task J. But the latter did not matter as the tasks I and J don’t share SemTokZ. At an
instant t2, if H new releases the SemTokl1 lets the task I take it. Even then it cannot run
because it is also waiting for taskJ to release the SemTokl2. The task J is waiting at a next
instant t3, for either H or I to release the Sem Tokl because it needs this to again enter a
critical section in it. Neither task I can run after instant t3 nor task J. There is a circuit!
dependency established between I and J. There is a circular dependency established between I
and}.

The above situation is also called a deadlock situation. On the interrupt by H, the task J.
before exiting from the running state, should have been put in queue-front so that later on, it
should frist take SemTokI, and the task I put in queue next for the same token, then the
deadlock would not have occurred.
16EE505 – MICROCONTROLLER AND EMBEDDED SYSTEMS UNIT - 5

Use of mutex solves the deadlock problem in certain OSs. Mutex use may not solve the
deadlock Situation in other RTOSs.