C# 4.0 "Fixes" Deadlock Issue

Posted by David West on Mar 11, 2009

Sections

Architecture & Design,

Development

Topics

.NET ,

Compilers ,

Programming ,

Design Guideline ,

Code Generation ,

Multi-threading

Share |

RELATED Research

A few years ago, Eric Lippert noted that an optimized and unoptimized build of the same source code could result in different potential deadlocks.  That problem was "fixed" in the 4.0 release of C#.  'Fixed' is in quotation marks because the cure is not without its own problems.

The original problem arose from the possibility of the compiler inserting no-op instructions when translating IL to machine code in an inconsistent manner; depending on the way you selected to turn on/off optimization and debugging.  Lippert noted:

Recall that lock(obj){body} was a syntactic sugar for

var temp = obj;
Monitor.Enter(temp);
try { body }
finally { Monitor.Exit(temp); }

The problem here is that if the compiler generates a no-op instruction between the monitor enter and the try-protected region then it is possible for the runtime to throw a thread abort exception after the monitor enter but before the try. In that scenario, the finally never runs so the lock leaks, probably eventually deadlocking the program. It would be nice if this were impossible in unoptimized and optimized builds.

The solution however has it own issues. According to Eric, "It is consistently bad now, which is better than being inconsistently bad.  But there's an enormous problem... implicit in this codegen is the belief that a deadlocked program is the worst thing that can happen. That's not necessarily true.

The purpose of a lock is to protect a mutable resource, or stated another way to protect potentially multiple users of that mutable resource from accessing a corrupt version of the resource.  The current 4.0 solution does not include rollback to original state or guarantee of completion of a mutation.  It is possible for an exception to occur that forces a branch to the finally clause of the lock statement, releasing the lock and allowing access to any waiting thread to the corrupted resource.  The solution made a tradeoff of consistency of results, and reducing the possibility of deadlocks, at the cost of potentially accessing corrupt state.  This problem is particularly risky in multi-threaded programming.

This specific tradeoff involves a choice between two bad results:  deadlock the program or fail to protect the state of a critical resource.  This specific example is but one of several design decisions and tradeoffs that we are forced to make when doing multi-threaded programming.

A number of developers responded by noting that this kind of design problem is not unique to multi-threading and that there is a difference between "lock safety" and "exception safety."  Lippert responded by agreeing that multi-threading only makes a hard problem harder, and that "getting the locks right is only the first step," your design still needs to deal with all other kinds of exceptions and how they should be handled.  A large number of respondents made points about the danger of aborting threads and agreeing, for the most part, with Lippert that, "aborting a thread is pure evil."

1. Back to top

   Asynchronous Exceptions are Evil

   by Ben Murphy

   looks like .NET people are learning what java people did years ago. Thread.stop is evil. :)

   Reply

2. Back to top

   Re: Asynchronous Exceptions are Evil

   by Sebastian Rowe

   Good point Ben, interesting how C# looks so similar to Java. Guess they copied the good and the bad from Java.

   Reply