![](https://secure.gravatar.com/avatar/718de1c5c11f194993698a8d0301ca3a.jpg?s=120&d=mm&r=g)
I have been digging into Python threading and was curious as to whether I'm going to run into problems using Python threads with numpy. So, my questions are: 1) Does numpy (or numarray) release the Python GIL? 2) If not, why not? Is this simply something I could fix by making the changes myself, or are there larger reasons for not releasing the GIL? Thanks, -a
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Wed, 2003-04-30 at 02:47, Andrew P. Lentvorski, Jr. wrote:
1) Does numpy (or numarray) release the Python GIL?
numarray does not explicitly release the GIL. There is a long standing doubt that Python callbacks made from its extension functions may make numarray unsound for multi-threaded work because they *do* release the GIL.
2) If not, why not?
It just hasn't been a priority yet for numarray.
Is this simply something I could fix by making the changes myself,
Don't know.
or are there larger reasons for not releasing the GIL?
Don't know.
![](https://secure.gravatar.com/avatar/a53ea657e812241a1162060860f698c4.jpg?s=120&d=mm&r=g)
On Wednesday 30 April 2003 08:47, Andrew P. Lentvorski, Jr. wrote:
1) Does numpy (or numarray) release the Python GIL?
No.
2) If not, why not? Is this simply something I could fix by making the changes myself, or are there larger reasons for not releasing the GIL?
There is one good reason, which is that the GIL release code doesn't nest. If NumPy released the GIL during its operations, then any C code that uses NumPy functions would have to reacquire the GIL before calling NumPy, then re-release the GIL afterwards. In most real-life situations, it is simpler and presumably more efficient to release the GIL once for a block of numerical computations, which would include many calls to NumPy functions. One could of course release the GIL not within the functions that are part of the NumPy C API, but in a thin wrapper around it that is directly called from Python. The only other problem that I see is the general object type arrays, which make calls back into the Python interpreter. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Wed, 2003-04-30 at 02:47, Andrew P. Lentvorski, Jr. wrote:
1) Does numpy (or numarray) release the Python GIL?
numarray does not explicitly release the GIL. There is a long standing doubt that Python callbacks made from its extension functions may make numarray unsound for multi-threaded work because they *do* release the GIL.
2) If not, why not?
It just hasn't been a priority yet for numarray.
Is this simply something I could fix by making the changes myself,
Don't know.
or are there larger reasons for not releasing the GIL?
Don't know.
![](https://secure.gravatar.com/avatar/a53ea657e812241a1162060860f698c4.jpg?s=120&d=mm&r=g)
On Wednesday 30 April 2003 08:47, Andrew P. Lentvorski, Jr. wrote:
1) Does numpy (or numarray) release the Python GIL?
No.
2) If not, why not? Is this simply something I could fix by making the changes myself, or are there larger reasons for not releasing the GIL?
There is one good reason, which is that the GIL release code doesn't nest. If NumPy released the GIL during its operations, then any C code that uses NumPy functions would have to reacquire the GIL before calling NumPy, then re-release the GIL afterwards. In most real-life situations, it is simpler and presumably more efficient to release the GIL once for a block of numerical computations, which would include many calls to NumPy functions. One could of course release the GIL not within the functions that are part of the NumPy C API, but in a thin wrapper around it that is directly called from Python. The only other problem that I see is the general object type arrays, which make calls back into the Python interpreter. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
participants (3)
-
Andrew P. Lentvorski, Jr.
-
Konrad Hinsen
-
Todd Miller