What's the cost of releasing the GIL?

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.

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.

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.

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.

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

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 at 22:39.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.