What's the cost of releasing the GIL?

Question

Let's suppose I have a C extension function that does something that is completely independent of the Python interpreter. Is there any reason not to release the GIL?

For example, is there any reason not to write code like this (apart from issues like readability and avoiding micro-optimization - things that are important, but not really relevant to my question)?

Py_BEGIN_ALLOW_THREADS
    a = 1 + 1;
Py_END_ALLOW_THREADS

Clearly, this is trivial code where performance probably won't matter too much. But is there any performance reason not to release the GIL here? Or should the GIL only be released for more CPU-intensive code?

Answer 1

The GIL is an ordinary mutex. The cost of locking or unlocking an uncontested mutex is extremely low, not much more than the cost of changing a global variable. However, if you lock and unlock a contested mutex very often, the cost of the mutex can become significant.

So, this is not usually a good idea:

Py_BEGIN_ALLOW_THREADS
    a = 1 + 1;
Py_END_ALLOW_THREADS

What is happening here is you are unlocking a mutex that you try to lock again immediately afterwards. If this is a break between two large chunks of code, then it gives another thread a chance to run. But if you don't have problems with threading granularity, just keep the lock.

So it's a good idea in this context:

very_long_computation_requires_gil();
Py_BEGIN_ALLOW_THREADS;
a = a + i;
Py_END_ALLOW_THREADS;
very_long_computation_also_requires_gil();

It's really impossible to make an educated guess without knowing the context, and it's often still difficult without running tests.

Answer 2

Experts are still tweaking and testing about GIL.

This are new ideas about a old problem : inside-look-at-gil-removal-patch

You can also consider to try Stackless Python ( no GIL ) or PyPy ( Python with Just-In-Time compiler ).

Answer 3

If you have a C extension function that does something that is completely independent of the Python interpreter, then releasing the GIL is usually a good idea. The only downside is waiting to get the GIL back. In Python 3.2, you have to wait a minimum of 1/20th of second.

Answer 4

Is there any reason not to release the GIL?

If the C extension calls non re-entrant code, then you could have problems if multiple Python threads call in to the extension at the same time. So you may want to avoid releasing the GIL in such extensions to protect against this happening (of course you could create your own mutex at the Python level or C level to achieve this without affecting other threads).

Or should the GIL only be released for more CPU-intensive code?

Another main reason for releasing the GIL is when calling a C extension that blocks (such as a blocking read on a socket) to enable other threads to run. This is exactly what happens when the Python interpreter itself executes a blocking operation in a thread.