[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: lock contention - what can we do about it?
From:       David Nolden <zwabel () googlemail ! com>
Date:       2011-03-09 17:02:45
Message-ID: AANLkTinwkfNFZbf_zMc0nO-Tb2KXNe84Yfos0vE5YqeV () mail ! gmail ! com
[Download RAW message or body]

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

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]