[C++-sig] Managing the GIL across competing threads

[Adam Preble]

Well the current design does have a problem, but I think it's more to do
with the Python side than the sum of the whole thing.  Most of my threads
are basically subsystems in their own rights, and whatever that subsystem
manage is encapsulated inside it.  I get into this little spats when I need
to request a resource from one or more of them--not necessarily from one
subsystem to another, just in my main script I have to create an object
that involves a piece from one and a piece from another.  The subsystems
will normally get to them when they are not in their own critical sections.
 I just got bit when they both went through what is essentially an
unprotected interpreter.

So I assume I would satisfy your suggestion of a master lock if I basically
put the interpreter in its own subsystem.  Everybody then gets their turn
at it.

Something I'm curious about has to do with the busy what in my promises and
future implementation.  When I end up waiting on something, is there a way
right now with Python to give up the GIL until the wait is done?  If I were
to do a Release before the wait and an Ensure right after it, will there be
inconsistent issues?  I ask this despite probably trying it tonight since
these are the kind of issues that tend to bite me after the fact and not up
front.

On Fri, Mar 16, 2012 at 10:38 AM, Niall Douglas
<s_sourceforge at nedprod.com>wrote:

> The key to avoiding deadlocks is, in every case, the appropriate
> design.
>
> In what you posted you appear to be doing too much at once, so you're
> holding onto too many locks at once. Either replace those with a
> single, master lock or try to never hold more than one lock at any
> one time. That includes the GIL. In well designed code, one almost
> NEVER holds more than two locks at any time.
>
> Consider breaking object instantiation up into well defined stages.
> Consider throwing away your current implementation entirely and
> starting from scratch. Debugging a bad design will take longer and
> cost more than throwing it away and starting again with the benefit
> of hindsight.
>
> Niall
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120316/aeb846eb/attachment.html>