Logged In: YES 
user_id=31435

It appears you're concerned that the signal will "get lost" 
in this scenario.  I agree that it may, but it doesn't 
matter:  thread 2's "while (thelock->locked)" test fails 
because thread 1 already set thelock->locked to 0, so 
thread 2 doesn't execute its pthread_cond_wait, so it 
doesn't matter that nobody is *waiting* to see thread 1's 
pthread_cond_signal.  IOW, the condition thread 1 will try 
to signal has *already* been detected by thread 2, and the 
signal is useless (because redundant) information.  Indeed, 
it's a beauty of the condition protocol that signals can be 
sloppy.

The linuxthread man page is worded strangely here, but note 
that it does not say the mutex *must* be locked.  They 
can't, either, because POSIX doesn't require it; while 
POSIX stds aren't available freely online, some derived 
specs are, and are much clearer about this; e.g., see the 
Single Unix Specification, here:

<http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_con
d_signal.html>

I'll tell you why I don't *want* to change this:  in 
Python's use of the global interpreter lock, it's almost 
always the case that someone is waiting on the lock.  By 
releasing the mutex before signaling, this gives a waiter a 
chance to run immediately upon calling 
pthread_cond_signal.  Else, because pthread_cond_wait 
(which the waiters are executing) has to lock the mutex, if 
the signaler is holding the mutex during the signal, 
pthread_cond_signal can't finish the job -- it was to go 
back to the signaler and let it unlock the mutex first 
before a waiter can proceed.  This makes the region of 
exclusion longer than it needs to be.

So if there's not an actual race problem here (& I still 
don't see one), I don't want to change this.