global interpreter lock not working as it should

[anton wilson]

On Tuesday 30 July 2002 04:55 am, Martin v. Löwis wrote:
> Just <just at xs4all.nl> writes:
> > I can see it on MacOSX, three different Linux boxes and a FreeBSD box.
> > Various Python versions. The output is always sequential.
>
> As Aahz explains, that can indeed happen (and, depending on the thread
> implementation of your operating system, might be even likely to
> happen).  It is in no way "wrong". 


I would disagree.
In the Python documentation it states:

"In order to support multi-threaded Python programs, the 
interpreter regularly releases and reacquires the lock -- by default, every 
ten bytecode instructions "


What's the purpose of releasing an reaquiring the lock if no other threads 
can run? It's easy to say that one can't assume about the order of running on 
different platforms as a scapegoat, but the main problem is that the GIL is 
NOT implemented properly with pthreads. So nearly every system that uses 
pthreads will show this kind of queue behaviour. I have a feeling that there 
is a hidden race condition between when the thread wakes up the other thread 
and tries to reaquire the lock. It really should be fixed, or else what's the 
point of threads? Threads are for concurrency! 

Anton




>Please replace the for statement
> with a while 1: loop - even on systems where my script produces
> sequential output, I find that the operating system will eventually
> switch threads.
>
> Regards,
> Martin