analyzing lock contention in multi-threaded app?

[Skip Montanaro]

    Tim> [Skip]
    >> I was reading the PEP 319 thread on python-dev yesterday and a
    >> question popped into my brain with recurs (to me) from time-to-time.
    >> Is there a decent way to analyze a multi-threaded app for lock
    >> contention?

    Tim> No, locks are too low-level.  If you have to use locks, ensure that
    Tim> no thread ever requires holding more than one lock at a time.  Then
    Tim> deadlock is impossible.  If a thread has to hold more than one lock
    Tim> at a time, then ensure that all threads acquire locks in a fixed
    Tim> global order; then deadlock is also impossible.  Regardless of
    Tim> approach, strive to hold locks over as small a stretch of code as
    Tim> possible.

I can see I was too vague in my description.  I'm not really concerned with
deadlock since no thread holds more than one lock at a time.  I'm more
interested in knowing if a thread had to wait to get a lock or take an
object off the queue.

After my post it occurred to me that instead of simply calling
lock.acquire(), since I only use blocking calls to get locks, I could define
an acquire method which looks like this:

    def acquire(lock, name):
        result = lock.acquire(blocking=False)
        if not result:
            log("lock wait: %s" % name)
            lock.acquire()
        return True

and then call:

    lock = threading.RLock()
    ...
    self.acquire(lock, "purpose")
    try:
        block
    finally:
        lock.release()

I think that will probably serve my needs at some small extra cost to
acquire locks.

Skip