[Nepomuk] High mutex contention in Nepomuk2::Resource

[Simeon Bird]

> Oh..... well, you found it: resourcewatcher.cpp uses
> QDBusConnection::sessionBus()!

Aha!

> Can you reproduce that crash, i.e. can you test if that fixes it?

Alas, no.

> Yes, I need to take the time to write a blog post on how to set up Qt for
> helgrind (and helgrind for Qt). Ping me back about this in a few days if I
> don't move forward on it :)

Thanks very much.

> Which caller, and which lock? I see no lock in the watcher -- and if you mean
> the ResourceManager lock, that one is already too much of a contention point,
> we should definitely not re-use it for objects that are independent from
> ResourceManager.
> [But of course one could say ResourceWatcher is not really independent --- I'm
> lacking a big picture design about this... I should go back in time and ask
> Vishesh in Berlin...]

Originally I was thinking the big lock, which, most of the time, was
already held by
the ResourceData method that called addToWatcher, but then I thought of a way to
avoid the lock being taken in the ResourceData method, so we can't do
that anymore :)
So I added an extra mutex for the ResourceWatcher, but I'll switch it
to the single-thread stuff you
suggest.

>> I guess there are two possible fixes:
>> 1) Just protect the ResourceWatcher with the rm mutex.
>> 2) Call all methods via a QAutoConnection
>>
>> I like the first, because I don't really understand what is happening with
>> the moveToThread stuff, but is there some reason I am missing why the mutex
>> is not enough and this is really necessary?
>
> I'd prefer solution 2, so that the watcher lives in a single thread entirely,
> which is important for libdbus usage -- and which will give better performance
> than locking the big mutex even more than today.

hmm, this is more tricky - we need to safely access
m_watcher->resourceCount() somehow,
although I think I see a way around that...

> Can I let you make and test these changes?

Sure. I don't want to commit some of these though, because of a plasma
bug (see my email a few minutes ago)
that makes the activity manager submit property changes as fast as it
can, which becomes bad if submitting property changes is actually
fast.

Thanks,
Simeon