Thread-safety issue in cmake support ?

Christoph Cullmann cullmann at
Sat Jun 12 05:29:35 UTC 2010

On Friday 11 June 2010 21:10:52 David Nolden wrote:
> That is ugly (IMO) and complicated though, because you need a lot of
> changes to the codebase, and whenever you want to use something from
> within the background thread you have to thing hard how to get it there.
> It's much simpler to simply introduce a big lock through which you can
> access anything, and then make sure it's used seldomly enough and only for
> short intervals to make sure there is a minimum amount of lock contention.
It's not ugly, it's the way nearly all other threading or multi-process 
systems work, that need data-passing. (Even on machines with a single shared 
I know from my work, how locking harms performance, even only one or two small 
locks can just kill the performance enough, that a efficient single-thread 
implementation beats a multi-thread implementation.

> It wouldn't even be desirable to eliminate all instances of the lock, as
> the lock would achieve the same as a message-passing interface between the
> foreground and background which would be the alternative, just with much
> less code.
But with lot more lock contention. The GUI will hold the lock often, for each 
event, ....

> I'm pretty sure that only very few instances of the big lock would cause
> performance issues. We can identify those instances and think out something
> better there, but for most usecases the foreground lock should work
> perfectly, because (at least in c++ support), access to foreground data is
> only needed in few cases.
If the accesses are that rare, it would be not much work and code to port them 
to work on local stored stuff, or?
Else, you contradict yourself, and they are not that seldom at all and you 
will get your performance penalty from the locks.


-------------------------------------- Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

More information about the KDevelop-devel mailing list