LockSet implementation and unit tests
authorGuido Trotter <ultrotter@google.com>
Thu, 28 Feb 2008 15:06:19 +0000 (15:06 +0000)
committerGuido Trotter <ultrotter@google.com>
Thu, 28 Feb 2008 15:06:19 +0000 (15:06 +0000)
commitaaae9bc0033f02780f90332eec82db3ed018d9b9
treed6ce5ceab5a4156352ea8cbc389b0241d1d3cf2f
parentf3b100e1e1d1ac760d8e13d60c278b09f5d03254
LockSet implementation and unit tests

A LockSet represents locking for a set of resources of the same type. A thread
can acquire multiple resources at the same time, and release some or all of
them, but cannot acquire more resources incrementally at different times
without releasing all of them in between.

Internally a LockSet uses a SharedLock for each resource to be able to grant
both exclusive and shared acquisition. It also supports safe addition and
removal of resources at runtime. Acquisitions are ordered alphabetically in
order to grant them to be deadlock-free. A lot of assumptions about how the
code interacts are made in order to grant both safety and speed; in order to
document all of them the code features pretty lenghty comments.

The test suit tries to catch most common interactions but cannot really tests
tight race conditions, for which we still need to rely on human checking.

This is the second basic building block for the Ganeti Lock Manager. Instance
and Node locks will be put in LockSets to manage their acquisition and release.

Reviewed-by: imsnah
lib/locking.py
test/ganeti.locking_unittest.py