Fix LockSet._names() to work with the set-lock
authorGuido Trotter <ultrotter@google.com>
Thu, 11 Sep 2008 09:43:04 +0000 (09:43 +0000)
committerGuido Trotter <ultrotter@google.com>
Thu, 11 Sep 2008 09:43:04 +0000 (09:43 +0000)
If the set-lock is acquired, currently, the _names function will fail on
a double acquire of a non-recursive lock. This patch fixes the behavior,
and some lines of code added to the testAcquireSetLock test check that
this and other functioins behave properly.

Reviewed-by: imsnah

lib/locking.py
test/ganeti.locking_unittest.py

index aaae252..a35767f 100644 (file)
@@ -390,11 +390,17 @@ class LockSet:
     Used only for debugging purposes.
 
     """
-    self.__lock.acquire(shared=1)
+    # If we don't already own the set-level lock acquired
+    # we'll get it and note we need to release it later.
+    release_lock = False
+    if not self.__lock._is_owned():
+      release_lock = True
+      self.__lock.acquire(shared=1)
     try:
       result = self.__names()
     finally:
-      self.__lock.release()
+      if release_lock:
+        self.__lock.release()
     return set(result)
 
   def acquire(self, names, blocking=1, shared=0):
index e23f0b4..a43e1b7 100755 (executable)
@@ -393,6 +393,9 @@ class TestLockSet(unittest.TestCase):
   def testAcquireSetLock(self):
     # acquire the set-lock exclusively
     self.assertEquals(self.ls.acquire(None), set(['one', 'two', 'three']))
+    self.assertEquals(self.ls._list_owned(), set(['one', 'two', 'three']))
+    self.assertEquals(self.ls._is_owned(), True)
+    self.assertEquals(self.ls._names(), set(['one', 'two', 'three']))
     # I can still add/remove elements...
     self.assertEquals(self.ls.remove(['two', 'three']), ['two', 'three'])
     self.assert_(self.ls.add('six'))