Python threading (was: Re: global interpreter lock not working as it should)

[Martin v. Löwis]

a-steinhoff at web.de (Armin Steinhoff) writes:

> > Because of this code in thread_pthread.h
> > 
> > 	status = pthread_mutex_lock( &thelock->mut );
> 
> this starts a critical section for the handling of 'thelock->locked'
> It will (must) block other threads which are trying to update
> 'thelock->locked'

It does try to update ->locked, but no, there is no other thread
trying to update that data at the same time (normally).

> > 	CHECK_STATUS("pthread_mutex_lock[1]");
> > 	success = thelock->locked == 0;
> > 	if (success) thelock->locked = 1;
> 
> 'success' will always be 0 ... so why 'if(success)' ??????
> We are in a critical section !!!

No. Read the source again. success is only 0 if locked is not 0,
i.e. if somebody else has locked the lock.

> > 	if ( !success && waitflag ) {
> 
> The variable 'success' is meaningless ... who sets the waitflag ??

The variable is not meaningless. waitflag is set by the caller of
lock(), and indicates whether lock should block if the lock is not
available, or return without locking the lock.

> > 		/* mut must be locked by me -- part of the condition
> > 		 * protocol */
> > 		status = pthread_mutex_lock( &thelock->mut );
> > 		CHECK_STATUS("pthread_mutex_lock[2]");
> 
> There is nothing to check ... you own now simply the mutex here.

First of all, we don't own the mutex at this point - it was previously
unlocked. Furthermore pthread_mutex_lock can fail for various reasons,
ENOMEM among them.

> The while loop is plain nonsens and dangerous because 'thelock->mut'
> isn't acquired again!!

The loop is not plain nonsens, and it is not dangerous. thelock->mut
is acquired again (three statements, and all three wrong :-)

> > 		while ( thelock->locked ) {
> > 			status = pthread_cond_wait(&thelock->lock_released,
> > 						   &thelock->mut);
> > 			CHECK_STATUS("pthread_cond_wait");
> 
> After calling pthread_cond_wait() the mutex 'thelock->mut' will be
> released!

Not sure what you mean here. When pthread_cond_wait returns, the mutex
is locked.

> The mutex 'thelock->mut' is only used to build a critical section
> around the condition variable 'thelock->lock_released'

No. That is not true. It is part of the condition variable protocol.

> Who does pthread_cond_signal() and when ???

Read the man page.

> > 		thelock->locked = 1;
> 
> That's really corious ... 

You show a deep lack of knowledge with regard to POSIX threads. I
suggest that you read some documentation first.

> > Nobody is blocking on the mutex;
> 
> Sorry ... that's not true! Please read the semantic of
> pthread_mutex_lock.

It is true. Read the semantics of pthread_cond_wait.

> This code looks like a MEDIUM chaos for me ... 

I'm not surprised that it does. That is not because of the code,
though, just because you are not understanding it.

> It should  be possible to implement the GIL by a single condition
> variable!

Read the semantics of pthread_cond_wait. It requires a mutex.  Also
notice that pthread_cond_wait may return spontaneously.  Finally,
consider that PyThread_allocate_lock needs to support the waitflag.

Regards,
Martin