What is a deadlock?

A Common Misnomer in IT industry

In an earlier posting, I proposed a new way to help remember the difference between “mean”, “median”, and “mode”, using etymology as a memory aid. Now I want to talk about another technical term that system analysts or anyone in IT may use, often incorrectly, “deadlock”.

What is a deadlock? If your coworker says his (or her) software program gets stuck, he may say “it’s in a deadlock”, as if “deadlock” means “getting stuck”. But if he’s a little more technical, his “deadlock” means “a lock that blocks execution of his program”. The first usage is very wrong (unless he’s a poet and recites that term in such a style). The second usage is less so, but wrong still.

“Deadlock” does not necessarily refer to a lock that hangs for a long time or forever. If you delete a row in a table in a database without commit, so your coworker can still see the row, and if he deletes the row, his session will hang, either forever or till you commit or rollback. (But in MySQL with autocommit off, his session will time out.) But neither yours or his session is ever in a deadlock, even though the locking situation looks as unmovable as a dead carcass. So, if that “dead” locking is not a deadlock, what is one? Consider this in an Oracle database (in other databases, you may have to turn off autocommit first):

In session A: update tb set col=’x’ where pk=’aa’; In session B: update tb set col=’x’ where pk=’bb’; In session A: update tb set col=’x’ where pk=’bb’; In session B: update tb set col=’x’ where pk=’aa’;

This will create a deadlock, in its technically accurate sense. A relational database is normally designed to automatically handle a deadlock. In Oracle, 3 seconds after a deadlock is created, one of the sessions involved in the deadlock will be rolled back. In MySQL, immediately. So, while “deadlock” sounds scarier than “lock”, maybe due to the necrotic adjective “dead”, it actually locks for a very short time, as if death could be revived. And a simple lock that blocks another resource will look dead forever or till human intervention (or in MySQL, timeout).

If we want to summarize the above in technical jargon, a deadlock involing two processes is as follows. But of course it’s not limited to only 2 processes.

/ Process P1 holds an exclusive lock on resource R1 and waits for process P2, which holds an exclusive lock on resource R2, to release the lock so that P1 can acquire an exclusive lock on R2. But at this time, P2 also waits for P1’s lock on R1 to be released. As a result, both processes will wait forever unless there is an agreement between them or a third party intervenes to break the deadlock, such as deciding that one of the processes gives up exclusive holding of the resource or reduces the exclusive lock to a shared lock. /

OK. Next time you hear your coworker saying “my program is in a deadlock”, you know he’s using the term in layman’s terms. Make a judicious decision on whether to correct him.