Logged In: YES 
user_id=246388

> 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.

Yes, I assume thread 3 completed in this gap and it is 
possible.

"Collide" means while thread 2's pthread_cond_wait was 
modifiying the internal data structure, thread 1 calls 
pthread_cond_signal.

The point here is not missing signals, the problem is the 
possiblity that pthread_cond_signal preempt the execution 
of pthread_cond_wait.  I can't find any document says 
pthread_cond_xxx functions must be automic operations.

In pthread_cond_xxx man page, it only mentioned:

pthread_cond_wait atomically unlocks  the  mutex  (as  per
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pthread_unlock_mutex) and waits for the condition variable
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cond to be signaled. The thread execution is suspended and
^^^^^^^^^^^^^^^^^^^
does not consume any CPU time until the condition variable
is signaled. The mutex  must  be  locked  by  the  calling
thread on entrance to pthread_cond_wait.  Before returning
to the calling thread, pthread_cond_wait re-acquires mutex
(as per pthread_lock_mutex).

Unlocking  the mutex and suspending on the condition vari­
able is done  atomically.  Thus,  if  all  threads  always
acquire  the  mutex  before  signaling the condition, this
guarantees that the condition cannot be signaled (and thus
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
ignored) between the time a thread locks the mutex and the
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
time it waits on the condition variable.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I take it that between the time the mutex is locked by 
pthread_mutex_lock and unlocked by pthread_cond_wait, you 
can't call pthread_cond_signal.  I also browse through 
LinuxThread implementation and can't find pthread_cond_xxxx 
is implemented automically.

I found there is another way to fix this without having to 
call the pthread_cond_signal while holding the mutex.  If 
we do:

if (!thelock->locked)
  status = pthread_cond_signal( &thelock->lock_released );

we guarantee that when pthread_cond_signal is called, the 
acquire_lock code will not be in the middle of 
pthread_cond_signal.