BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

C# 4.0 "Fixes" Deadlock Issue

by David West on Mar 11, 2009 |

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."

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Asynchronous Exceptions are Evil by Ben Murphy

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

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT