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?

Kaplan

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.

Dank

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.

Kind

Answer 3

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.

Bladderwort

Answer 4

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 ).

Publicist

I don't understand the down vote. My answer is a reference to a best-of-all discussion, where Guido and other developers compare different problems and different solutions about GIL. None answers here touch that level of details and know-how. – Publicist

It's simple: Your post does not answer the question. (Note that it wasn't me who down-voted it, though) – Rockey

Ferdinand, I agree my link is not a complete answer, but I still think it is better than other users' guesses. Moreover I suggest Stackless and PyPy, aren't they a practical answer ? – Publicist

You see, the OP knows about the GIL and probably also knows about alternatives. But the question is very specific: Using CPython as it is, when writing an extension in C, is it a good idea to release the GIL often or are there downsides? That's why your answer is not useful at all (compare it to the accepted answer). But don't worry too much about the downvote. – Rockey