Patch: wake up duchainlock writers

[David Nolden]

Am Dienstag 15 Dezember 2009 02:04:53 schrieb Hamish Rodda:
> When I said it was slower, I meant it seemed like the background parsing
>  was slower, but I didn't measure it.  Given you've found it's faster,
>  that's most likely the case.  I didn't try to determine the UI
>  responsiveness.  The lock still prefers waiting readers over writers, so
>  the UI should still be as fast (given the main thread should only ever use
>  readers).
> 
> If the user time is increased, that just means we were better at utilising
>  the multiple CPUs, right?  Ideally we want utilisation at 100% x all cpus,
>  which should result in much better wall clock time but higher user time.
That time should count the 'overall' CPU usage, and if it's higher, it means 
that we've burnt more CPU cycles to get the same result.

> > Due to the central nature of the duchain lock, I'm actually thinking of
> > replacing all the mutexes in there with spin-locks, using QAtomicInt
> >  instead of all the mutexes and wait conditions, to make the whole thing
> >  more efficient.
> 
> What are the performance differences with multiple threads in release mode?
>  I think that is what we should be targeting, as it is our core audience
>  (developers usually have decent machines).
I've implemented my idea now, and it is much faster. Locking the duchain now 
approximately equals increasing one counter, and eventually waiting.

> These locks are (best I can determine):
>   961: duchain lock
> 11330: within KDevelop::Identifier
>  4679: within Utils::BasicSetRepository
> 22794: within KDevelop::IndexedString
> 28228: within KDevelop:shouldDoDUChainReferenceCountingInternal
>   718: duchain lock wait condition (presumably the reader condition?)
>  4669: another Utils::BasicSetRepository
>   391: duchain lock wait condition (presumably the writer condition?)
> 26929: QAbstractFileEngine::create(QString)
>   979: within KDevelop::DUChain::self
> 
> So, there are a number of places that may benefit from spin locking, if we
> find that we can do them faster than mutexes.
There is definitely some other places that can profit from a spin-lock, but it 
won't change much about these 'waiting' times, it can just make the 
performance a bit better. To reduce these waiting times, we might in future 
introduce some simple spin-lock based read-write locks, to allow accessing the 
resources by multiple threads at the same time.

Greetings,
David