global interpreter lock not working as it should

[Martin v. Löwis]

anton wilson <anton.wilson at camotion.com> writes:

> 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. I DO 
> expect a thread to block on the GIL every 10 byte codes. 

That expectation is wrong. The thread will release the GIL every 10
byte codes. Whether that results in blocking is the operating system's
choice.

> However, I have proved with my results that this does NOT
> happen. Any thread that is completely CPU bound will never give up
> the CPU for as long as
> 1) it can run
> 2) it has work to do

I believe this is not true. The system will schedule a different
thread eventually, atleast on all systems I could try.


> The great majority of the time, my print statement will be printed, meaning 
> the GIL was not released.

But sometimes, it was released? Then everything is working as designed.

> > Lo and behold, each thread is getting execution time, and nearly equal
> > execution time at that!
> 
> 
> There are several reasons why your program seems to work.
> The first obvious reason is that the main thread sleeps. 

So what? Does that make the claim false that all other threads get equal time?

> This proves that the GIL does not block very often, and definitely not every 
> 10 byte codes. Think about this for a while.

Nobody said there will be thread switch every 10 byte code
instructions. In fact, doing that will be very expensive.

> Here, you will notice that there are constant changes. The GIL releasing is 
> working as intended.

No, it's not. The intention of the GIL is different.

> 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. 

Indeed, and that is the intention of the GIL: When the
system-allocated slice has expired, a thread switch should occur. For
that to happen, the GIL must be, and is, released.

> Because the thread is never forced by the OS to relinquish the CPU, the 
> thread will never ever lose the GIL. If the GIL was actually working corectly 
> and blocking, the second thread would not retain the CPU past 10 byte codes.

It would not be correct if the GIL was blocking.

> So, the GIL does not blcok as intended, and this probably needs to be looked 
> into.

It does not always block, and this is as intended.

Regards,
Martin