9

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?

Jason Baker
  • 192,085
  • 135
  • 376
  • 510

4 Answers4

9

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.

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
1

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.

Raymond Hettinger
  • 216,523
  • 63
  • 388
  • 485
0

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.

aaa90210
  • 11,295
  • 13
  • 51
  • 88
0

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

Massimo
  • 3,171
  • 3
  • 28
  • 41
  • 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. – Massimo Nov 26 '11 at 22:39
  • 1
    It's simple: Your post does not answer the question. (Note that it wasn't me who down-voted it, though) – Ferdinand Beyer May 18 '12 at 05:48
  • 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 ? – Massimo May 20 '12 at 22:17
  • 1
    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. – Ferdinand Beyer May 21 '12 at 07:19