Why/How python3 schedules threads in creation order?

Question

The following code prints False on python27 and True on python36 on my Mac.

from threading import Thread


def make_huge_list(amount):
    my_list = []

    def add_num(num):
        my_list.append(num)

    threads = [Thread(target=add_num, args=(i,)) for i in range(amount)]

    for t in threads:
        t.start()
    for t in threads: t.join()

    return my_list


if __name__ == '__main__':
    # check the output is ordered
    print(make_huge_list(100000) == list(range(100000)))

I know that GIL improvements were added in python3 for better scheduling/fairness. I'm puzzled on how/why this codes prints True on python36.

score 1 · Accepted Answer · answered Jan 04 '18 at 09:52

In Python3.2 the GIL handling was changed (read more here)

the change that mainly effects the code above is how the GIL is reacquired after a release.

Before the change python would have release the GIL and all threads would battle for it, which means that after the main thread creates a thread it releases the GIL and try to reacquire it, which means the schedule might look like this

MT -> T1 -> MT ->T2 -> MT -> MT ->T4 -> T3 ...

In python3.2 a thread releases the GIL and signals other threads to take it, so it won't take the GIL again, the schedule will look like this:

MT -> T1 -> MT ->T2 -> MT -> T3 -> MT -> T4 ...

only two threads will be active in the same time :)

Why/How python3 schedules threads in creation order?

1 Answers1