title: pthread_cond_signal causing deadlock
body: <p>I have a program that deadlocks when one of the threads calls <code>pthread_cond_siganl</code> (or broadcast).
  The problem is reproducible 100% in the main program. I could not figure out what is wrong with it and thus extracted the piece of code that wait and signal are called. However, the deadlock <strong>cannot</strong> be reproduced with the extracted problem.</p>
  
  <p>Running <code>valgrind</code> on the main program does not report any invalid reads/writes or memory leaks.</p>
  
  <p>I want to know what are the possible reasons for a deadlock when calling <code>pthread_cond_signal</code>.</p>
  
  <p>The extracted snippet follows.</p>
  
  <pre><code>#include &lt;pthread.h&gt;
  #include &lt;math.h&gt;
  #include &lt;syscall.h&gt;
  #include &lt;assert.h&gt;
  #include &lt;stdlib.h&gt;
  #include &lt;iostream&gt;
  
  using namespace std;
  
  void Task() {
      cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " In Task, sleeping..." &lt;&lt; endl;
      sleep(5);
  }
  
  pthread_mutex_t lock;
  pthread_cond_t cond;
  bool doingTheTask= false;
  
  void* func(void* ) { 
      pthread_mutex_lock(&amp;lock);
      if (doingTheTask) {
          cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " wait... " &lt;&lt; endl;
          while ( doingTheTask) {//spurious wake-up
              cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " waiting..." &lt;&lt; endl ;
              pthread_cond_wait(&amp;cond, &amp;lock);
              cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " woke up!!!" &lt;&lt; endl ;
          }
      }
      else {
          cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " My Turn to do the task..." &lt;&lt; endl;
          assert( ! doingTheTask );
          doingTheTask= true;
          pthread_mutex_unlock(&amp;lock);
          Task();
          cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " Before trying to acquire lock" &lt;&lt; endl;
          pthread_mutex_lock(&amp;lock);
          cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " After acquiring lock" &lt;&lt; endl ;
          assert( doingTheTask );
          doingTheTask = false;
          cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " Before broadcast" &lt;&lt; endl;
          pthread_cond_broadcast(&amp;cond);
          cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " After broadcast" &lt;&lt; endl;
      }
      pthread_mutex_unlock(&amp;lock);
      return NULL;
  }
  
  
  int main() {
      pthread_mutex_init(&amp;lock,NULL);
      pthread_cond_init(&amp;cond,NULL);
      pthread_t thread[2];
  
      for ( int i = 0 ;  i &lt; 2 ; i ++ ) {
          if (0 != pthread_create(&amp;thread[i], NULL, func, NULL) ) {
              cerr &lt;&lt; syscall(SYS_gettid) &lt;&lt; " Error creating thread" &lt;&lt; endl;
              exit(1);
          }
      } 
  
      for ( int i = 0 ;  i &lt; 2 ; i ++ ) {
          pthread_join(thread[i],NULL);
      }
      pthread_mutex_destroy(&amp;lock);
      pthread_cond_destroy(&amp;cond);
  
      return 0;
  }
  </code></pre>
  
  <p>The only important part is the func function. The other parts are just presented in order to compile.</p>
  
  <p>As I said the problem <strong>is not reproducible in this program</strong>. 
  The difference between this snippet and the main program are:</p>
  
  <ul>
  <li>In the main program, the <code>mutex</code> and <code>condvar</code> are member fields and the function is a member method.</li>
  <li>The task does some task instead of sleeping.</li>
  <li>Multiple threads may wait and we should broadcast rather than signal. However, deadlock is 100% reproducible even when I use signal and one waiting thread.</li>
  </ul>
  
  <p>The problem that I am trying to solve with this piece of code is a mechanism to do the task once when at least one of the threads needs it to be done. But no two threads should do the task in parallel and once one of them does the task, the others do not need to do it. The clients of this method assume that it blocks until the task is done (thus I cannot return immediatly after seeing that someone is doing the task).</p>
  
  <p>The backtrace of the deadlocked threads are:</p>
  
  <pre><code>#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
  #1  0x00007ffff73e291c in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:259
  </code></pre>
  
  <p>and</p>
  
  <pre><code>#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
  #1  0x00007ffff73e30b1 in pthread_cond_signal@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_signal.S:142
  </code></pre>
  
  <p><a href="https://stackoverflow.com/questions/4345315/pthread-cond-signal-deadlocks">pthread_cond_signal deadlocks</a> is a similar problem. But seems like the one asking question had memory corruption. I do not have memory corruption (says <code>valgrind</code>).</p>
  
  <p>The problem is 100% reproducible on the two machines I tested it on. (ArchLinux latest and Uubntu 10.04.3).</p>
  
  <p>A sample output of the main program follows. It again shows that the threads block before calling <code>pthread_cond_wait</code> and <code>pthread_cond_signal</code>. (The first column shows the thread ids).</p>
  
  <pre><code>3967    In Task, sleeping...
  3967    My Turn to do the task...
  3967    In Task, sleeping...
  3973    wait...
  3973    waiting...
  3976    &lt;output from some other thread&gt;
  3967    Before trying to acquire lock
  3967    After acquiring lock
  3967    Before broadcast
  </code></pre>
  
  <p>The main program is in C++. But I am using the C parts of the language and thus avoided using C++ tag.</p>