Serializing PyThreads without holding interpreter lock?

Albert Hofkamp hat at
Tue Mar 18 10:30:30 CET 2003

On Mon, 17 Mar 2003 17:25:01 +0100, Martin v. Löwis <martin.vonloewis at> wrote:
>> At first sight, a solution to this problem seems to be releasing the
>> global interpreter lock, by
>> around the  call to the solver, and
> here.

Maybe. I do need access to the state though, because I have to pass it on
through the solver code down to the call-back functions, which need to
restore the state before jumping back to Python. After the call to Python
returns, I need to save the state again, so I can restore it after the call
to the solver.

>> 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?
> I recommend to put another lock around the solver code. See _tkinter.c
> for an example; it also puts Tcl into a lock. This requires a few additional
> macros, since you need a state where you hold both locks, and a state
> where you just hold the solver lock.

Tnx for the pointer.
Luckily, my situation is somewhat easier because the solver is not
multi-threaded. (phew!)

>> The Python C programming manuals do give a number of primitives for
>> handling thread, but blocking threads is not part of the provided
>> functionality.
> That's not true. If you allocate additional locks, waiting for these locks
> will block the calling thread if another thread already holds the lock.

I just checked again, PyThread_lock_type, PyThread_acquire_lock, and
PyThread_release_lock are _NOT_ in the (index of the) C/API manual and
neither are they in the embedding/extending manual, at least I couldn't
find them.

Maybe there are other manuals that describe thread-programming in Python?

Anyway, I think I have enough information to solve our problem.
Tnx everybody.

Unlike popular belief, the .doc format is not an open publically available format.

More information about the Python-list mailing list