Logged In: YES 
user_id=31435

> The problem will be arised if there is a thread 3
> called PyThread_acquire_lock 

You never mentioned thread 3 again, so I don't know what it 
has to do with this.

> after thread 1 set thelock->locked to 0 and before
> thread 2 calling pthread_mutex_lock. 

I understand both of those.  Are you assuming that, e.g., 
thread 3's PyThread_acquire_lock completes in whole during 
this gap?  I don't know what else you could mean, so let's 
assume that.

> "while (thelock->locked)" will success for thread 2

Sure.

> and it will call pthread_cond_wait

Yup.

> and might collide with thread 1's pthread_cond_signal.

What does "collide" mean to you?  All the pthread_cond_xxx 
functions must be implemented as if atomic, so there's no 
meaningful sense (to me) in which they can collide -- 
unless they're implemented incorrectly.

Assuming they are implemented correctly, it again doesn't 
matter that thread 2 misses thread 1's signal, because 
thread *3* exploited the information thread 1 was going to 
signal, by acquiring the lock.  It's actually good that 
thread 2 isn't bothered with it:  there's no real info in 
the signal anymore (at best, if thread 2 got it, it would 
wake up and go "oops! it's still locked; I'll wait again").

All that matters now is whether thread 2 gets a chance to 
see thread *3*'s signal, at the time thread 3 releases the 
lock.  And it will, because thread 3 can't release the lock 
without acquiring the mutex first, and thread 2 holds the 
mutex at all times except when in its pthread_cond_wait 
call (so thread 3 can't release the lock except when thread 
2 is in pthread_cond_wait).

Note that I'm not at all concerned about "fairness" here, 
only about races.