global interpreter lock not working as it should

[anton wilson]

On Tuesday 30 July 2002 07:18 pm, brueckd at tbye.com wrote:
> On Tue, 30 Jul 2002, anton wilson wrote:
> > Maybe I am not being clear enough. I am concerned with a multi-threaded
> > program that does not do any form of blocking on a Linux/Unix box.
>
> Quick tangential question: if there's no blocking of any kind, why are you
> using threads, anyway? Off the cuff thinking says this seems like a misuse
> of them.

For a real-time system. ;) It will work. It would just be nice if they 
switched exactly every 10 byte codes becuase that means they only use about 
10 to 20 milliseconds each.


> > [0, 0, 0]
> >
> > ....(100+ times in all)...
> >
> > [35499, 16419, 0]
> >
> > ...(100+ times in all) ....
> >
> > [35499, 16419, 11556]
> >
> > This proves that the GIL does not block very often, and definitely not
> > every 10 byte codes. Think about this for a while.
>
> <sigh> No, it doesn't "prove" anything about the GIL. Without the print
> statements, the main thread is spinning like crazy - the other threads
> probably aren't even getting _started_ right away. 

The rest of the input shows that the lock is released and immediately 
reacquired even after threads start. The second set of printouts look like 
[35499, 16419, 0]. So the threads have started. Then the main thread prints 
out about 130 of those statements. That is past 10 byte codes. Therefore, it 
was releasing and reacquiring without hindrance.

> Note that if you try the above experiment in C (start 3 threads and
> immediately have main thread spin and print out wildly) you'll get very
> similar output (lots of [0,0,0]'s printed at the beginning, etc). 

This should happen. I was just counting on python to force a 10 byte-code 
block once the threads did get started. Wrong assumption, but it nice 
assumption to be able to make.

I really wanted it to run and block every time. It actually does wake up the 
other thread, it just doesn't block like I wanted it to. 


>
> Just curious: how do you explain all the multithreaded Python programs
> that currently work just fine? Are these all flukes?

This brings me to the second reason that your program seems to work.
The Linux OS gives threads time-slices and when these time-slices are used up 
every 150 or so milliseconds, the process is forcibly removed from the CPU.
I presume that the reason your program seems to work is that in the time 
between when a thread releases the GIL and a thread tries to reaquire the 
GIL, it is forcibly removed from the CPU, and the other thread can now run. 
This would not be a rare occurence due to the high frequency at which the 
lock is released.

> -Dave