PyThread_acquire_lock freezes at pthread_cond_wait although lock not occupied

[Gernot Hillier]

Hi!

Jeremy Hylton wrote:
> A condition variable that is waiting does not hold the lock.  You can

I think you misunderstood me. I don't speak about a Python-level condition 
variable. I mean the condition variable which is used internally to 
implement the lock:

I'll quote Python/thread_pthread.h (shortened): 

PyThread_acquire_lock(PyThread_type_lock lock, int waitflag)
{
        status = pthread_mutex_lock( &thelock->mut );
        success = thelock->locked == 0;
        if (success) thelock->locked = 1;
        status = pthread_mutex_unlock( &thelock->mut );

        if ( !success && waitflag ) {
                status = pthread_mutex_lock( &thelock->mut );
                while ( thelock->locked ) {
                        status = pthread_cond_wait(&thelock->lock_released,
                                                   &thelock->mut);
                }
                thelock->locked = 1;
                status = pthread_mutex_unlock( &thelock->mut );
                success = 1;
        }
        if (error) success = 0;
        return success;
}

So if I'm understanding this right, pthread_cond_wait() will be only called 
if the lock is held and ...

void
PyThread_release_lock(PyThread_type_lock lock)
{
        status = pthread_mutex_lock( &thelock->mut );
        thelock->locked = 0;
        status = pthread_mutex_unlock( &thelock->mut );

        status = pthread_cond_signal( &thelock->lock_released );
}

... will be signalled as soon as the GIL is released.

So IMHO thelock->locked MUST be 1 while pthread_cond_wait is blocking.

But sometimes it isn't :-(

> If you have a multi-threaded application, you should look at what all
> the other threads are doing.  One of the other threads has the lock
> and hasn't released
> it. 

That was my first idea, but no other thread is doing anything Python-related 
at the moment the one thread is blocking.

And what is very astonishing is the fact that other threads can (later on) 
quite happily acquire and release the GIL as often as they want to - my 
firstly started thread still blocks at the cond_wait() call and will do so 
forever :-(

> There's a good chance that there is inconsistent use of app-level
> locking with the GIL.

Possible, but I tripled checked all parts of my programs - and that wouldn't 
explain how a similar block can occur with the import_lock - as I don't use 
this thingie myself anywhere in my code...

-- 
Ciao,

Gernot