Remember of use PyEval_InitThreads on your module initialization. Renato Araujo Oliveira Filho
On Tue, Feb 2, 2010 at 2:30 PM, Matthew Scouten (TT) < matthew.scou...@tradingtechnologies.com> wrote: > First of all, the PyGILState_* functions are acquiring and releasing the > “Global Interpreter _*Lock*_” Your _pyMutex is redundant. > > Here are the rules that govern the GIL: > > 1) Only one thread at a time can hold the GIL > > 2) Any thread that is touching python data, python code, or any part > of the ‘terp must hold the GIL > > > > The python part of your program WILL be single threaded. There is nothing > you can do about that. > > > > *From:* cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com@ > python.org > [mailto:cplusplus-sig-bounces+matthew.scouten<cplusplus-sig-bounces%2Bmatthew.scouten> > =tradingtechnologies....@python.org] *On Behalf Of *Pascal Briet > *Sent:* Tuesday, February 02, 2010 5:46 AM > *To:* cplusplus-sig@python.org > *Subject:* [C++-sig] PyGILState_Release with multithread > > > > Hello, > > > > After a few days of headache, I think the best way is to share this > problematic… > > > > I have : > > - a main Python script > > - a C module imported and called from Python (thanks to boost ::python) > > - A dozen of threads created by a C function (boost ::thread) > > - These threads, in a C main loop, call regularly a Python function. > > > > > > Here is the critical part of the C code, with the Python GIL management : > > > > boost::mutex _pyMutex; > > PyGILState_STATE _gstate; > > > > _pyMutex.lock(); > > _gstate = PyGILState_Ensure(); > > _pyMutex.unlock(); > > > > // Interprets Python bytecodes with boost::python > > > > _pyMutex.lock(); > > PyGILState_Release(_gstate); > > _pyMutex.unlock(); > > > > > > This part is multi-threaded, and it seems that the PyGILState_* functions > do not like it. > > I have the following error with PyGILState_Release : « This thread state > must be current when releasing » > > > > I think that when 2 threads enter PyGILState_Ensure, the second one is > considered as the current one. When the first one end… it is not current. A > quick look to the code of the Python API seems to confirm it. > > > > > > So, the only solution I found is to lock the whole call to Python : > > > > boost::mutex _pyMutex; > > PyGILState_STATE _gstate; > > > > _pyMutex.lock(); > > _gstate = PyGILState_Ensure(); > > > > // Interprets Python bytecodes with boost::python > > > > PyGILState_Release(_gstate); > > _pyMutex.unlock(); > > > > > > Everything is ok with this solution, except that… only one thread at a > time can call a Python method. > > When 2 threads ask for a Python call, if the first one is a blocking > operation, the second one will wait… it is so bad ! > > > > Do you have any solution ? > > > > Nb : I use Python 2.5.2 > > > > Thanks for your help. > > > > > > *_____* > > > > *Briet Pascal* > > Ingénieur d'études > > > > +33 (0)1 47 42 10 55 > > > > OptimProcess > > 32 rue Tronchet - 75009 Paris > www.optimprocess.com > > > > > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig@python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig >
<<image001.jpg>>
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
