lock contention - what can we do about it?

David Nolden zwabel at googlemail.com
Wed Mar 9 17:02:45 UTC 2011


This is interesting, now we have at least a lock which we can point at.

The DUChainLock is a RW-Lock, which means that it allows many
concurrent readers, but only one writer. Parsing threads are designed
in a way, that they acquire the Write-lock only for very short
periods. Maybe we can make these periods even smaller. The read-lock
on the other hand is acquired for arbitrarily long periods.

When a thread is waiting on the duchain lock, then it basically means:
A) The thread wants a write-lock, but other threads are holding read-locks
or
B) The thread wants a read-lock, but another thread is holding the write lock

Since the parse-jobs are designed in a way to hold the write-lock only
for very short periods, I guess the problem is A).

Write-locks are acquired only for very short periods, but they are
also acquired very frequently when parsing, for every single
encountered declaration. I guess we need to somehow reduce the
frequency of write-locks, maybe by batching multiple changes into a
single lock, or something like that.

However, beforehand, it would be good to do some more profiling, to
see where to start. A callgrind run on the no-usleep version would
reveal the places where most of the waiting is taking place.

Greetings, David




More information about the KDevelop-devel mailing list