analyzing lock contention in multi-threaded app?
tim.one at comcast.net
Tue Jun 17 20:16:11 CEST 2003
> 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
More information about the Python-list