Question

I have the following code:

def query(self,query):
  lock = QMutexLocker(self.mutex)
  reply = self.conn.query(query)
  if (re.search("error", reply) != None):
    raise GeneralError("Query error")

  #more code...  
  return reply

Now, if the exception is thrown lock doesnt seem to be deleted, cause the mutex is not released. I can ofcourse do “del lock” everywhere, but that takes away the whole point of qmutexlocker. Does this have to do with Python garbage-collection? If so, that must mean QMutexLocker is not usable at all in Python?

Answer 1

If you want the mutex released prior to raising an exception, then release it:

def query(self, query):
    lock = QMutexLocker(self.mutex)
    reply = self.conn.query(query)
    if re.search("error", reply):
        lock.unlock()
        raise GeneralError("Query error")

If you are hoping that when lock goes out of scope that it will be instantly released, you are expecting too much of the interpreter. Since you know exactly when and why the lock should be released, do it.

As a general rule — Python or elsewhere — you should always have a mutex bound the smallest possible action. I’ll assume that you know that whatever query is doing actually requires protection and it will still need it after the call to self.conn.query.

added in response to comment:

That’s a fair point that “must mean QMutexLocker is not usable at all” which I did miss. I assume you are referring to PySide.QtCore.QMutexLocker which makes the unlikely claim:

Now, the mutex will always be unlocked when the
PySide.QtCore.QMutexLocker object is destroyed (when the function
returns since locker is an auto variable).

It is unlikely because there is no such thing as an auto variable storage class in Python. I suspect this will, upon further investigation, prove to be a “let’s just wrap a C++ library and assume the scoping semantics work”. If this guess is correct you might feasibly use the with statement to better guarantee reliable unlocking.