analyzing lock contention in multi-threaded app?

[Tim Peters]

[Skip Montanaro]
> I can see I was too vague in my description.

Nope, I just decided to answer an interesting question instead <wink>.

> 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.

Well, on a uniprocessor box and an app with N threads, the best you can hope
for is that each thread spends (N-1)/N of its time waiting for something.

> 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:
> ...

Or continue to use blocking acquires and just capture time.time() on each
side.  You'll want to stuff a thread id and timestamp into each log entry
too.