GIL behavior in python 3.7 multithreading

Question

I am researching and trying to understand the python GIL and best practices to use multithreading in python. I found this presentation and this video

I tried to reproduce the strange and crazy problems mentioned in the first 4 slides of the presentation. This problem also mentioned by the lecturer in the video(first 4 minutes). I wrote this simple code to reproduce the problem

from threading import Thread
from time import time

BIG_NUMBER = 100000
count = BIG_NUMBER


def countdown(n):
    global count
    for i in range(n):
        count -= 1


start = time()
countdown(count)
end = time()
print('Without Threading: Final count = {final_n}, Execution Time = {exec_time}'.format(final_n=count, exec_time=end - start))

count = BIG_NUMBER
a = Thread(target=countdown, args=(BIG_NUMBER//2,))
b = Thread(target=countdown, args=(BIG_NUMBER//2,))
start = time()
a.start()
b.start()
a.join()
b.join()
end = time()
print('With Threading: Final count = {final_n}, Execution Time = {exec_time}'.format(final_n=count, exec_time=end - start))

but the results are completely different from the paper and video! executing time with threading and without threading are almost the same. sometimes one of both case is a bit faster than the other.

here is a result I got using CPython 3.7.3 under Windows 10 using a multicore architecture processor.

Without Threading: Final count = 0, Execution Time = 0.02498459815979004
With Threading: Final count = 21, Execution Time = 0.023985862731933594

also what I understand according to the video and the paper is GIL prevent real parallel execution of two thread at the same time in two core. so if this is true, Why the final count variable (in multithreading case) is not zero as expected and will be a different number at the end of each execution probably because of manipulation of threads at the same time? does anything changes happen to GIL in newer pythons than the video and the paper(which use python 3.2) cause these different? thanks in advance

Answer 1

Python is not executed directly. It is first compiled into so called Python bytecode. This bytecode is similar in its idea to raw assembly. The bytecode is executed.

What GIL does it doesn't allow two bytecode instructions to run in parallel. Although some opeartions (e.g. io) do release the GIL internally to allow real concurrency when it can be proved that it cannot break anything.

Now all you have to know is that count -= 1 does not compile into a single bytecode instruction. It actually compiles into 4 instructions

LOAD_GLOBAL              1 (count)
LOAD_CONST               1 (1)
INPLACE_SUBTRACT
STORE_GLOBAL             1 (count)

which roughly means

load global variable into local variable
load 1 into local variable
subtract 1 from local variable
set global to the current local variable

Each of these instruction is atomic. But the order can be mixed by threads and that's why you see what you see.

So what GIL does it makes the execution flow serial. Meaning instructions happen one after another, nothing is parallel. So when you run multiple threads in theory they will perform the same as single thread minus some time spent on (so called) context switch. My tests in Python3.6 confirm that the execution time is similar.

However in Python2.7 my tests showed significant performance degradation with threads, about 1.5x. I don't know the reason for this. Something other then GIL has to happen in the background.