title: Why does Python threading.Condition() notify() require a lock?
body: <p>My question refers specifically to why it was designed that way, due to the unnecessary performance implication.</p>
  
  <p>When thread T1 has this code:</p>
  
  <pre><code>cv.acquire()
  cv.wait()
  cv.release()
  </code></pre>
  
  <p>and thread T2 has this code:</p>
  
  <pre><code>cv.acquire()
  cv.notify()  # requires that lock be held
  cv.release()
  </code></pre>
  
  <p>what happens is that T1 waits and releases the lock, then T2 acquires it, notifies <code>cv</code> which wakes up T1. Now, there is a race-condition between T2's release and T1's reacquiring after returning from <code>wait()</code>. If T1 tries to reacquire first, it will be unnecessarily resuspended until T2's <code>release()</code> is completed.</p>
  
  <p><strong>Note:</strong> I'm intentionally not using the <code>with</code> statement, to better illustrate the race with explicit calls.</p>
  
  <p>This seems like a design flaw. Is there any rationale known for this, or am I missing something?</p>