Thread-safety issue in cmake support ?

Milian Wolff mail at
Fri Jun 11 19:43:28 UTC 2010

Nicolás Alvarez, 11.06.2010:
> On 6/11/10, David Nolden <zwabel at> wrote:
> > The big lock wouldn't eliminate multithreading at all.
> > 
> > For example in the c++ support, it is needed only once at the beginning
> > of a parse job to get the include paths, and maybe a few times during
> > the code completion, which is quite tightly coupled to the UI anyway.
> > Ok, it would also be required for using the new smart-ranges for
> > highlighting, but that could be combined into one single locking per
> > parsed open document, and thus wouldn't be critical.
> > 
> > The important task is just to make sure the lock is used as seldomly as
> > possible, and to make sure that all the heavy-lifting is done in a long
> > continuous phase without the lock. That is easy for c++ support at least.
> In my experience, the C++ parser *already* has too much lock
> contention (from duchain locks). I rarely see KDevelop CPU usage go
> above 100%.
> I just tried wiping .kdevduchain and starting kdevelop again, and it
> averaged 85% CPU usage during background parsing. It's configured to
> use 2 threads and doesn't even manage to use a single CPU core
> fully...

I agree completely. I know from the few times I did such tests that two 
threads make parsing a big project only roughly 10% faster while three didn't 
improve that noticeably anymore...
Milian Wolff
mail at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the KDevelop-devel mailing list