Python global interpreter lock

This article explains the python GIL pretty well.

https://www.obytes.com/blog/2018/explaining-python-interpreter-lock/

In Python 2, a thread can at most perform 100 instructions/ticks before releasing the GIL. This setting can be changed with sys.setcheckinterval(). Then the OS will decide which thread will pick up the GIL next, possibly the same thread again based on the criteria the OS uses. The problem here is that the low-priority threads may keep waiting forever.

In Python 3, a thread can at most run for 5ms before releasing the GIL. Then with some system-level signals the same thread won’t pick up the GIL again immediately after. Sounds more fair. However since an I/O call will lead to voluntarily releasing the GIL, a thread with many I/O calls will keep losing the GIL to other CPU bound threads each time by 5ms (at most, say there is a long-running thread). So worst case scenario a thread with 1000 I/O calls will have an overhead of 1000 * 5ms = 5 sec. That’s quite something since you can save that 5 sec by running a non-threaded version. Ironic it is.

The root of the problem here is the GIL, or the fact that CPython is single-threaded for its memory management. Jython, IronPython, etc took away the GIL using transactional memory, but they don’t support C extensions.

Hopefully someday we will have CPython without the GIL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s