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

[Armin Steinhoff]

Tim Peters <tim.one at comcast.net> wrote in message news:<mailman.1028585237.3659.python-list at python.org>...
> [Bengt Richter]
> > ...
> > My impression was that it requires the mutex to be locked when called,
> > and unlocks it itself so as to wait unlocked, and then re-locks it for
> > the waiter. I.e., inside pthread_cond_wait:
> >   ...
> >   pthread_mutex_unlock(mutex);
> >   suspend_with_cancellation(self);
> >   pthread_mutex_lock(mutex);
> >   ...
> >
> > I guess the re-lock involves trying, though -- is that a tiny crack
> > for Murphy to sneak through?
> 
> The implementation of pthread_cond_wait can't be that simple; it's required
> to act "as if atomic":  a thread returning from that call *must* hold the
> mutex, and it's pthread_cond_wait's job to guarantee that.
> 
> > Ah, I guess that's why there's that 'while' in PyThread_acquire_lock:
> > 		...
> > 		while ( thelock->locked ) {
> > 			status = pthread_cond_wait(&thelock->lock_released,
> > 						   &thelock->mut);
> > 			CHECK_STATUS("pthread_cond_wait");
> > 		}
> > 		thelock->locked = 1;
> > 		...
> 
> No, this isn't to guard against broken pthread_cond_wait implementations.
> The POSIX spec for pthread_cond_signal allows that any number of threads may
> be signaled;

No ... only the first thread in the waiting queue get the state
'runnable'!
You have probably pthread_cond_broadcast in mind ....

However ... what I will do is a re-implementation of thread_pthread.h
in the sense of thread_cthread.h. The current thread_pthread is a
littlebit weird.

Armin

> specific implementations may guarantee to wake up exactly one,
> but that goes beyond what the phtread spec promises, so can't be relied on.
> If the signal does wake more than one thread, all but one of them will
> typically loop back to the pthread_cond_wait here.
> 
> This is all (including the loop) a perfectly vanilla use of the condvar
> protocol, BTW.
> 
> > ...
> > Thanks for your pointers. BTW, the source for the linuxthreads
> > (or whatever pthread package is actually used) is (AFAICS) not
> > included in the win32 python distribution.
> 
> No C source code is included in the Windows distro, beyond the .h files
> extension modules may need.
> 
> > Might this be a good idea for cross-platform documentation purposes?
> 
> That's what the source distributino is for.  The typical Windows user has no
> use for the C source code, and a few Windows users have kindly <wink> let it
> be known that they think the installer is already quite large enough.