Deadlock

From Wikipedia, the free encyclopedia

This article is about the computer science concept. For other uses, see Deadlock (disambiguation).

This article needs additional citations for verification.

Please help improve this article by adding reliable references. Unsourced material may
be challenged and removed. (August 2010)

A deadlock is a situation wherein two or more competing actions are each waiting for the other to finish, and
thus neither ever does. It is often seen in a paradox like the "chicken or the egg". "a lock having no keys"

When two trains approach each other at a crossing, both shall come to a full stop and neither shall
“ start up again until the other has gone.
”
— Illogical statute passed by the Kansas Legislature[1]

In computer science, Coffman deadlock refers to a specific condition when two or more processes are each
waiting for each other to release a resource, or more than two processes are waiting for resources in acircular
chain (see Necessary conditions). Deadlock is a common problem in multiprocessing where many processes
share a specific type of mutually exclusive resource known as a software lock or soft lock. Computers intended
for the time-sharing and/or real-time markets are often equipped with a hardware lock (or hard lock) which
guarantees exclusive access to processes, forcing serialized access. Deadlocks are particularly troubling
because there is no general solution to avoid (soft) deadlocks.

This situation may be likened to two people who are drawing diagrams, with only one pencil and one ruler
between them. If one person takes the pencil and the other takes the ruler, a deadlock occurs when the person
with the pencil needs the ruler and the person with the ruler needs the pencil to finish his work with the ruler.
Neither request can be satisfied, so a deadlock occurs.

The telecommunications description of deadlock is weaker than Coffman deadlock because processes can wait
for messages instead of resources. Deadlock can be the result of corrupted messages or signals rather than
merely waiting for resources. For example, a dataflow element that has been directed to receive input on the
wrong link will never proceed even though that link is not involved in a Coffman cycle.

[edit]Examples

An example of a deadlock which may occur in database products is the following. Client applications using the
database may require exclusive access to a table, and in order to gain exclusive access they ask for a lock. If
one client application holds a lock on a table and attempts to obtain the lock on a second table that is already
held by a second client application, this may lead to deadlock if the second application then attempts to obtain
the lock that is held by the first application. (But this particular type of deadlock is easily prevented, e.g., by
using an all-or-none resource allocation algorithm.)
Another example might be a text formatting program that accepts text sent to it to be processed and then
returns the results, but does so only after receiving "enough" text to work on (e.g. 1KB). A text editorprogram is
written that sends the formatter some text and then waits for the results. In this case a deadlock may occur on
the last block of text. Since the formatter may not have sufficient text for processing, it will suspend itself while
waiting for the additional text, which will never arrive since the text editor has sent it all of the text it has.
Meanwhile, the text editor is itself suspended waiting for the last output from the formatter. This type of
deadlock is sometimes referred to as a deadly embrace (properly used only when only two applications are
involved) or starvation. However, this situation, too, is easily prevented by having the text editor send
a forcing message (e.g. EOF, (End Of File)) with its last (partial) block of text, which will force the formatter to
return the last (partial) block after formatting, and not wait for additional text.

In communications, corrupted messages may cause computers to go into bad states where they are not
communicating properly. The network may be said to be deadlocked even though no computer is waiting for a
resource. This is in contrast to Coffman deadlock.

Nevertheless, since there is no general solution for deadlock prevention (there is, but until this is edited
otherwise, assume there isn't until reading Distributed deadlock prevention), each type of deadlock must be
anticipated and specially prevented. But general algorithms can be implemented within the operating system so
that if one or more applications becomes blocked, it will usually be terminated after (and, in the meantime, is
allowed no other resources and may need to surrender those it already has, rolled back to a state prior to being
obtained by the application). I believe Preemption_(computing) is the term being looked for here?

Mutual exclusion
From Wikipedia, the free encyclopedia

For the concept, see Mutually exclusive events.

Mutual exclusion (often abbreviated to mutex) algorithms are used in concurrent programming to avoid the
simultaneous use of a common resource, such as a global variable, by pieces of computer code calledcritical
sections. A critical section is a piece of code in which a process or thread accesses a common resource. The
critical section by itself is not a mechanism or algorithm for mutual exclusion. A program, process, or thread
can have the critical section in it without any mechanism or algorithm which implements mutual exclusion.

Examples of such resources are fine-grained flags, counters or queues, used to communicate between code
that runs concurrently, such as an application and its interrupt handlers. The synchronization of access to those
resources is an acute problem because a thread can be stopped or started at any time.
To illustrate: suppose a section of code is altering a piece of data over several program steps, when another
thread, perhaps triggered by some unpredictable event, starts executing. If this second thread reads from the
same piece of data, the data, which is in the process of being overwritten, is in an inconsistent and
unpredictable state. If the second thread tries overwriting that data, the ensuing state will probably be
unrecoverable. These shared data being accessed by critical sections of code, must therefore be protected, so
that other processes which read from or write to the chunk of data are excluded from running.

A mutex is also a common name for a program object that negotiates mutual exclusion among threads, also
called a lock.

[edit]Enforcing mutual exclusion

There are both software and hardware solutions for enforcing mutual exclusion. The different solutions are
shown below.

[edit]Hardware solutions
On a uniprocessor system a common way to achieve mutual exclusion inside kernels is to disable interrupts for
the smallest possible number of instructions that will prevent corruption of the shared data structure, the critical
section. This prevents interrupt code from running in the critical section, that also protects against interrupt-
based process-change.

In a computer in which several processors share memory, an indivisible test-and-set of a flag could be used in
a tight loop to wait until the other processor clears the flag. The test-and-set performs both operations without
releasing the memory bus to another processor. When the code leaves the critical section, it clears the flag.
This is called a "spinlock" or "busy-wait".

Similar atomic multiple-operation instructions, e.g., compare-and-swap, are commonly used for lock-
free manipulation of linked lists and other data structures.

[edit]Software solutions
Beside the hardware supported solution, some software solutions exist that use "busy-wait" to achieve the goal.
Examples of these include the following:

 Dekker's algorithm

 Peterson's algorithm

 Lamport's bakery algorithm

 The black-white bakery algorithm

Unfortunately, spin locks and busy waiting take up excessive processor time and power and are
considered anti-patterns in almost every case. In addition, these algorithms do not work if Out-of-order
execution is utilized on the platform that executes them. Programmers have to specify strict ordering on the
memory operations within a thread.

The solution to these problems is to use synchronization facilities provided by an operating system's
multithreading library, which will take advantage of hardware solutions if possible but will use software solutions
if no hardware solutions exist. For example, when the operating system's lock library is used and a thread tries
to acquire an already acquired lock, the operating system will suspend the thread using a context switch and
swaps it out with another thread that is ready to be run, or could put that processor into a low power state if
there is no other thread that can be run. Therefore, most modern mutual exclusion methods attempt to
reduce latency and busy-waits by using queuing and context switches. However, if the time that is spent
suspending a thread and then restoring it can be proven to be always more than the time that must be waited
for a thread to become ready to run after being blocked in a particular situation, then spinlocks are a fine
solution for that situation only.