[Nepomuk] High mutex contention in Nepomuk2::Resource

[Simeon Bird]

> (OK, working on this, but I'm fixing data races in Qt and bugs in helgrind
> along the way, so it will take a bit more time.)

That's ok - I'm don't have time to use it at the moment.

>> 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 :)
>
> "the ResourceData method" -- did you mean load()?
>
>> So I added an extra mutex for the ResourceWatcher, but I'll switch it
>> to the single-thread stuff you suggest.
>
> OK.
>
> In general I'm backing down a bit from "let's not use the big lock", though:
> I'm working on fixes so that it's not held for long (i.e. not during socket
> communication), so locking it for fast operations is fine.

I have some fixes for that too...I'll post them this evening (US time,
ie, in about 5 hours).
Basically it is no longer held during setProperty all the time.
At the moment what I did with the watcher was make the calls happen in
one thread, and protect
initialisation of m_watcher with the initMutex (which becomes a ReadWriteLock).

Do you think it is faster to use moveToThread, or protect it with a mutex?

>> hmm, this is more tricky - we need to safely access
>> m_watcher->resourceCount() somehow,
>> although I think I see a way around that...
>
> I think start and stop should simply be done inside the implementation of
> addResource/removeResource. This would solve the problem completely.
> Anything else is racy.

Agreed :) - what I did was to add two functions that started and stopped the
ResourceWatcher, as well as adding and removing the resource, because
I didn't want to change the behaviour of add/removeResource in a stable release.

Thanks for the patches, which I will try to review and test this evening.

Simeon