Serializing PyThreads without holding interpreter lock?

[Aahz]

In article <slrnb7bs8p.cbq.hat at se-46.wpa.wtb.tue.nl>,
Albert Hofkamp  <a.t.hofkamp at tue.nl> wrote:
>
>At first sight, a solution to this problem seems to be releasing the
>global interpreter lock, by
>1) adding Py_BEGIN_UNBLOCK_THREADS and Py_BEGIN_BLOCK_THREADS around the
>   call to the solver, and
>2) adding Py_BEGIN_BLOCK_THREADS and Py_BEGIN_UNBLOCK_THREADS around the
>   call-back interface code just before and after the Py_call_func() call.
>(and pass the PyThreadState around through the solver, from the solver call
>to the call-back code.)

Use Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS instead; makes your
life easier.

>However, releasing the global interpreter lock makes the solver re-entrant,
>i.e. a second thread could call the solver while the first thread is still
>computing. The solver library however cannot handle this situation, and
>will produce senseless results (so I assume).

Yup.

>The question is now how to prevent this from happening, i.e. how do I
>serialize calls to the solver without holding the global interpreter lock?
>A nice solution would be to block the second thread until the first thread
>is finished, e.g. by putting a P() and V() operation around the call to the
>solver.

I'd do this in Python interface to the solver, rather than in the C
library.  Just use a simple RLock().
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Register for PyCon now!  http://www.python.org/pycon/reg.html