How commonly do deadlock issues occur - in programming - not in the databases?

Question

I've programmed in a number of languages but am not aware of deadlocks in my code.

I took this to mean it doesn't happen.

Does this happen frequently enough that I should be concerned about it?

(I'm not even sure what to check.)

Answer 1

It would be very hard to give an idea of how often it happens in reality (in production code? in development?) and that wouldn't really give a good idea of how much code is vulnerable to it anyway. (Quite often a deadlock will only occur in very specific situations.)

I've seen a few occurrences, although the most recent one I saw was in an Oracle driver (not in the database at all) due to a finalizer running at the same time as another thread trying to grab a connection. Fortunately I found another bug which let me avoid the finalizer running in the first place...

Basically deadlock is almost always due to trying to acquire one lock (B) whilst holding another one (A) while another thread does exactly the same thing the other way round. If one thread is waiting for B to be released, and the thread holding B is waiting for A to be released, neither is willing to let the other proceed.

Make sure you always acquire locks in the same order (and release them in the reverse order) and you should be able to avoid deadlock in most cases.

There are some odd cases where you don't directly have two locks, but it's the same basic principle. For example, in .NET you might use Control.Invoke from a worker thread in order to update the UI on the UI thread. Now Invoke waits until the update has been processed before continuing. Suppose your background thread holds a lock with the update requires... again, the worker thread is waiting for the UI thread, but the UI thread can't proceed because the worker thread holds the lock. Deadlock again.

This is the sort of pattern to watch out for. If you make sure you only lock where you need to, lock for as short a period as you can get away with, and document the thread safety and locking policies of all your code, you should be able to avoid deadlock. Like all threading topics, however, it's easier said than done.

Answer 2

Deadlocks could arise if two conditions are true: you have mutilple theads, and they contend for more than one resource.

Do you write multi-threaded code? You might do this explicitly by starting your own threads, or you might work in a framework where the threads are created out of your sight, and so you're running in more than one thread without you seeing that in your code.

An example: the Java Servlet API. You write a servlet or JSP. You deploy to the app server. Several users hit your web site, and hence your servlet. The server will likely have a thread per user.

Now consider what happens if in servicing the requests you want to aquire some resources:

if ( user Is Important ){
     getResourceA();
}

getResourceB();

if (today is Thursday ) {
    getResourceA();
} 


// some more code

releaseResourceA();
releaseResoruceB();

In the contrived example above, think about what might happen on a Thursday when an important user's request arrives, and more or less simultaneously an unimportant user's request arrives.

The important user's thread gets Resoruce A and wants B. The less important user gets resource B and wants A. Neither will let go of the resource that they already own ... deadlock.

This can actually happen quite easily if you are writing code that explicitly uses synchronization. Most commonly I see it happen when using databases, and fortunately databases usually have deadlock detection so we can find out what error we made.

Defense against deadlock:

1. Acquire resources in a well defined order. In the aboce example, if resource A was always obtained before resource B no deadlock would occur.
2. If possible use timeouts, so that you don't wait indefinately for a resource. This will allow you to detect contention and apply defense 1.

Answer 3

All depends on what you are coding. Traditional single threaded applications that do not use locking. Not really.

Multi-threaded code with multiple locks is what will cause deadlocks.

I just finished refactoring code that used seven different locks without proper exception handling. That had numerous deadlock issues.

Answer 4

A deadlock is a situation with two processes are dependent on each other - one cannot finish before the other. Therefore, you will likely only have a deadlock in your code if you are running multiple code flows at any one time.

Developing a multi-threaded application means you need to consider deadlocks. A single-threaded application is unlikely to have deadlocks - but not impossible, the obvious example being that you may be using a DB which is subject to deadlocking.

Answer 5

If you get a chance take a look at first few chapters in Java Concurrency in Practice.

Deadlocks can occur in any concurrent programming situation, so it depends how much concurrency you deal with. Several examples of concurrent programming are: multi-process, multi-thread, and libraries introducing multi-thread. Many UI frameworks, especially timer event handling would be implemented as threads. Many web frameworks would spawn threads to handle multiple web requests simultaneously. With multicore CPUs you might see more concurrent situations visibly than before.

If A is waiting for B, and B is waiting for A, the circular wait causes the deadlock. So, it also depends on the type of code you write as well. If you use distributed transactions, you can easily cause that type of scenario. Without distributed transactions, you risk bank accounts from stealing money.

Answer 6

A common cause of deadlocks is when you have different threads (or processes) acquire a set of resources in different order.

E.g. if you have some resource A and B, if thread 1 acquires A and then B, and thread 2 acquires B and then A, then this is a deadlock waiting to happen.

There's a simple solution to this problem: have all your threads always acquire resources in the same order. E.g. if all your threads acquire A and B in that order, you will avoid deadlock.