title: Do zombies exist ... in .NET?
body: <p>I was having a discussion with a teammate about locking in .NET.  He's a really bright guy with an extensive background in both lower-level and higher-level programming, but his experience with lower level programming far exceeds mine.  Anyway, He argued that .NET locking should be avoided on critical systems expected to be under heavy-load if at all possible in order to avoid the admittedly small possibility of a "zombie thread" crashing a system.  I routinely use locking and I didn't know what a "zombie thread" was, so I asked.  The impression I got from his explanation is that a zombie thread is a thread that has terminated but somehow still holds onto some resources.  An example he gave of how a zombie thread could break a system was a thread begins some procedure after locking on some object, and then is at some point terminated before the lock can be released.  This situation has the potential to crash the system, because eventually, attempts to execute that method will result in the threads all waiting for access to an object that will never be returned, because the thread that is using the locked object is dead.  </p>
  
  <p>I think I got the gist of this, but if I'm off base, please let me know.  The concept made sense to me.  I wasn't completely convinced that this was a real scenario that could happen in .NET.  I've never previously heard of "zombies", but I do recognize that programmers who have worked in depth at lower levels tend to have a deeper understanding of computing fundamentals (like threading).  I definitely do see the value in locking, however, and I have seen many world class programmers leverage locking.  I also have limited ability to evaluate this for myself because I know that the <code>lock(obj)</code> statement is really just syntactic sugar for: </p>
  
  <pre><code>bool lockWasTaken = false;
  var temp = obj;
  try { Monitor.Enter(temp, ref lockWasTaken); { body } }
  finally { if (lockWasTaken) Monitor.Exit(temp); }
  </code></pre>
  
  <p>and because <code>Monitor.Enter</code> and <code>Monitor.Exit</code> are marked <code>extern</code>.  It seems conceivable that .NET does some kind of processing that protects threads from exposure to system components that could have this kind of impact, but that is purely speculative and probably just based on the fact that I've never heard of "zombie threads" before.  So, I'm hoping I can get some feedback on this here:</p>
  
  <ol>
  <li>Is there a clearer definition of a "zombie thread" than what I've explained here?</li>
  <li>Can zombie threads occur on .NET?  (Why/Why not?)  </li>
  <li>If applicable, How could I force the creation of a zombie thread in .NET?</li>
  <li>If applicable, How can I leverage locking without risking a zombie thread scenario in .NET?</li>
  </ol>
  
  <h1>Update</h1>
  
  <p>I asked this question a little over two years ago.  Today this happened:</p>
  
  <p><a href="https://i.stack.imgur.com/qd6Wd.png" rel="noreferrer"><img src="https://i.stack.imgur.com/qd6Wd.png" alt="Object is in a zombie state."></a></p>