[mod_python] Co-ordinating ccess to a single-use resource

Nicolas Lehuen nicolas.lehuen at gmail.com
Fri Sep 9 10:50:36 EDT 2005


This is a pretty simple Python error. What you want to write is :

import tconstants
tconstants.mutex.acquire()

or :

from tconstants import mutex
mutex.acquire()

but NOT :
import tconstants
mutex.acquire() # mutex is not defined here, it is defined in the
tconstants module...

Regards,
Nicolas

2005/9/9, John Simeone <jsimeone at inplex.com>:
>  Nicolas Lehuen wrote:
>  
>  2005/9/8, Graham Dumpleton <grahamd at dscpl.com.au>:
>  
>  
>  On 09/09/2005, at 2:23 AM, John Simeone wrote:
> 
>  
>  
>  Hello to everyone.
> 
> I am responsible for a project using Apache 2.0 with mod_python in a
> Win2k environment, the choice of OS being dictated by the fact that
> the purpose of the server is to supply access to a proprietary,
> supplier written Windows program to our user base via the web.
> 
> That program is single threaded and provides for only 1 user at a
> time. Access to the program in Python is through win32com.
> 
> I am using a mod_python.publisher handler.
> 
> All the http requests come through a single proxy server with a static
> address but not all are from browser clients. Some are originating
> from perl programs but all requests are directed to a single request
> handler.
> 
> Can anyone suggest a method to control access to this single user
> resource. In a non-web programming environment, I'd just use a mutex
> semaphore to co-ordinate access among the threads but I am too much of
> newbie with mod_python and Apache to implement a workable solution so
> far.
> 
> What mechanism can I use to create a shared resource that I can lock
> and have other requests wait until the resource is unlocked?
>  
>  When using mod_python under Win32 platform, there is effectively only
> one process and requests are handled in separate threads. Because of
> this, you should be able to mediate access to the shared resource
> through a normal thread mutual exclusion locking mechanism just as
> easily as you would in a non web environment.
> 
> Graham
>  
>  That is to say :
> 
> import threading
> 
> # "R" stand for Re-entrant, i.e. a thread can acquire the lock multiple
> times
> # make sure that the lock is instantiated only once, for example by
> putting it in
> # a module which your published code imports.
> lock = threading.RLock() 
> 
> lock.acquire()
> try:
>  # access the shared resource
> finally:
>  lock.release()
> 
> See the documentation of the threading module for more information.
> 
> Regards,
> Nicolas
> 
> 
>  
>  Thanks to Graham and Nicolas for their prompt responses.
>  
>  I followed Nicolas' counsel and created a file 'tconstants.py' :
>  
>  import threading
>  mutex = threading.RLock()
>  
>  included an 'import' into my publisher handler and wrapped the access to
> the single resource with 'mutex.acquire()' and mutex.release(). When I got
> an error regarding the unavailability of the mutex global, I ran the
> following test in IDLE:
>  
>  import threading
>  import tconstants
>  def setmutex():
>      mutex.acquire()
>      return
>  setmutex()
>  
>  and received the same error:  "global name 'mutex' is not defined."
>  
>  I ran the threading demo to verify there wasn't a problem with the thread
> module in my copy of Python 2.3. It ran fine.
>  
>  The only way I could get this test to work was to alter the code to define
> the mutex not in the imported tconstants but in the code directly:
>  
>  import threading
>  mutex = threading.RLock()
>  def setmutex():
>      mutex.acquire()
>      return
>  setmutex()
>  mutex.release()
>  
>  Will defining the mutex this way cause problems in proper threading control
> for mod_python in its interaction with Apache?
>  
>  Regards,
>  
>  John
>  
>  
>  
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
> 
> 
>



More information about the Mod_python mailing list