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

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.