title: Cancelling a thread that has a mutex locked does not unlock the mutex
body: <p>helping a client out with an issue that they are having.  I'm more of a sysadmin/DBA guy so I'm struggling with helping them out.  They are saying it is a bug in the kernel/environment, I'm trying to either prove or disprove that before I insist that it is in their code or seek vendor support for the OS.</p>
  
  <p>Happens on Red Hat and Oracle Enterprise Linux 5.7 (and 5.8), application is written in C++</p>
  
  <p>The problem they are experiencing is that the main thread starts a separate thread to do a potentially long-running TCP connect() [client connecting to server].
  If the 'long-running' aspect takes too long, they cancel the thread and start another one.</p>
  
  <p>This is done because we don't know the state of the server program:</p>
  
  <ul>
  <li>server program up and running --> connection immediately accepted</li>
  <li>server program not running, machine and network OK --> connection
  immediately failed with error 'connection refused' </li>
  <li>machine or network crashed or down --> connection takes a long time
  to fail with error 'no route to host'</li>
  </ul>
  
  <p>The problem is that cancelling the thread that has the mutex locked
  (with cleanup handlers set up to unlock the mutex) sometimes does NOT unlock the mutex.</p>
  
  <p>That leaves the main thread hung on trying to lock the mutex.</p>
  
  <p>Detailed environment info:</p>
  
  <ul>
  <li>glibc-2.5-65</li>
  <li>glibc-2.5-65</li>
  <li>libcap-1.10-26</li>
  <li>kernel-debug-2.6.18-274.el5</li>
  <li>glibc-headers-2.5-65</li>
  <li>glibc-common-2.5-65</li>
  <li>libcap-1.10-26</li>
  <li>kernel-doc-2.6.18-274.el5</li>
  <li>kernel-2.6.18-274.el5</li>
  <li>kernel-headers-2.6.18-274.el5</li>
  <li>glibc-devel-2.5-65</li>
  </ul>
  
  <p>Code was built with:
  c++ -g3 tst2.C -lpthread -o tst2</p>
  
  <p>Any advice and guidance is greatly appreciated</p>