[SciPy-user] odr thread safe?

Robert Kern robert.kern@gmail....
Wed Mar 21 12:42:12 CDT 2007


Christian wrote:
> Hi,
> I noticed that I cannot run odr more than once at a time using python threads.
> Is that true? Debugging yields:
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1294730336 (LWP 9312)]
> 0xb6fe0934 in fcn_callback (n=0xb2d3e9ec, m=0xb2d3e9e8, np=0xb2d3e9e4,
> nq=0xb2d3e9e0,
>     ldn=0xb2d3e9ec, ldm=0xb2d3e9e8, ldnp=0xb2d3e9e4, beta=0x90e0350,
> xplusd=0xb19b4e58,
>     ifixb=0x90e6580, ifixx=0x90e65d8, ldfix=0xb2d3e9c4, ideval=0xb701a098,
> f=0xb19d76e8,
>     fjacb=0xb19d8ec0, fjacd=0xb19b2008, istop=0xb2d3e288) at
> ./peak_o_mat/odr/__odrpack.c:70
> 70        Py_INCREF(odr_global.pyBeta);
> 
> Can someone advise me how to change the wrapper to be thread safe?

Hmm. I'm not sure how this is happening. Calls to extension functions should be
holding the global interpreter lock unless if it is explicitly released, and I'm
pretty sure that I'm not. It's possible that the GIL gets released when the
Python callbacks execute; I'd have to check. In that case, we would need a lock
around the call to __odrpack.odr().

But yeah, there's a difficult problem with calling a FORTRAN subroutine multiple
concurrent times. We need to pass function pointer callbacks to the FORTRAN
subroutine. These need to be real C functions. They can't have state, so the
state needs to be global. C++ methods don't work. Consequently, the Python
functions that the C callbacks will actually call are stored in odr_global.

Looking at the Python C API docs, a possibility is to use
PyThreadState_GetDict() to get a thread-specific dictionary. If threads aren't
being used, then you only get NULL, though, so another mechanism will have to
exist for the unthreaded case. I think. I could be misinterpreting the
documentation.

  http://docs.python.org/api/threads.html

Let me know what you come up with!

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


More information about the SciPy-user mailing list