[Python.NET] AcquireThreadLock - bug? future?

Roman Yakovenko roman.yakovenko at gmail.com
Mon Mar 14 14:08:19 CET 2005


On Mon, 14 Mar 2005 07:07:31 -0500, Brian Lloyd <brian at zope.com> wrote:
> Essentially the engine needs to own the thread lock in
> order to call Python C API functions. When a (managed)
> method is called, the MethodBinder:
> 
>   - releases the lock (so that other threads could
>     potentially run)
> 
>   - calls the managed method
> 
>   - re-acquires the lock after the call (because it
>     needs to use the C API again to Pythonify the
>     result, etc.)
> 
> So it sounds like some thread is unable to re-acquire
> the lock. This gets tricky _really_ quickly, because
> you can actually be calling a managed object that may
> later call back into Python code... etc.
> 
> Note that this doesn't happen for properties, because I
> arbitrarily decided that since properties are expected to
> to be lightweight that it wasn't worth the overhead ;)

I never wrote programs using Python C API. I think this is the first reason why
I don't understand why I should acquire thread lock Pythonify the
result. I definitely will read python manuals. An other thing that I
understand from your answer is that if I wrote property that takes
time ( for example server.IsConnected - makes ping to the remote
server ) I will run into some undefined behaviour ? I don't have
enough knowledge. Could you propose some solution ? If you need more
information I can debug application.


> 
> Brian Lloyd        brian at zope.com
> V.P. Engineering   540.361.1716
> Zope Corporation   http://www.zope.com
> 
> 
> > -----Original Message-----
> > From: pythondotnet-bounces at python.org
> > [mailto:pythondotnet-bounces at python.org]On Behalf Of Roman Yakovenko
> > Sent: Monday, March 14, 2005 1:24 AM
> > To: pythondotnet at python.org
> > Subject: [Python.NET] AcquireThreadLock - bug? future?
> >
> >
> > Hi. I have small problem with multithreading and need help to solve it.
> > I have dll written in managed C++. Within dll I have class that has
> > static function. I'd like to call this function from a few threads
> > from python. I failed to do this. Calling function staled and this is
> > a stack dump from debugger ( of my program )
> >
> > python.runtime.dll!Python.Runtime.PythonEngine.AcquireThreadLock()
> >  + 0x40 bytes
> >
> > python.runtime.dll!Python.Runtime.MethodBinder.Invoke(int inst =
> > 11793552, int args = 9900080, int kw = 0) + 0xf0 bytes
> >
> > python.runtime.dll!Python.Runtime.MethodObject.Invoke(int target =
> > 11793552, int args = 9900080, int kw = 0) + 0x25 bytes
> >
> > python.runtime.dll!Python.Runtime.MethodBinding.tp_call(int ob =
> > 11794928, int args = 9900080, int kw = 0) + 0x137 bytes
> >
> > I don't understand:
> >     1. Why Python.Net tries to acquire thread lock, while calling
> > function ?
> >         I am possible to call get property from a few threads. From
> > managed C++ point of view ( I could be wrong here ) getting value of
> > property it is just syntax sugaring for get_??? call. I want to say
> > that if I able to call "get property" from a few threads I should be
> > able to call function from a few threads.
> >     2. Why at all Python.Net tries to synchronize function calls?
> >
> > I can modify and compile source code of Python.Net, but I know to
> > little about reasons
> > of calling AcquireThreadLock.
> >
> > Thanks for help
> >
> > Roman
> > _________________________________________________
> > Python.NET mailing list - PythonDotNet at python.org
> > http://mail.python.org/mailman/listinfo/pythondotnet
> >
>


More information about the PythonDotNet mailing list