[Nepomuk] High mutex contention in Nepomuk2::Resource

[David Faure]

Debugging slowness in kmail showed me an issue there:

209│ bool Nepomuk2::Resource::hasProperty( const QUrl& uri ) const
210│ {
211├>    determineFinalResourceData();
212│     return m_data->hasProperty( uri );
213│ }

Even though we prepare the resource in a different thread (in 
asyncnepomukretriever) so all props are available, we're waiting on the 
ResourceManager mutex in that method, to read the properties.

Ah, but determineUri() does nothing if m_uri is set (not empty), anyway.
So how about the attached patch?

Note that I detected an error in the use of the "modification mutex" within 
Resource. I had used it only for "writes" to variables, but obviously the 
reads must be mutex-protected too. Now that I understand the C++11 memory 
model, it's a lot clearer :)
I'll rename the mutex then, it's not a "modification mutex", it's a mutex for 
the resource member variables.

Anyhow, please validate the URI thing -- am I right that it's empty initially,  
and then it's set (in determineUri()), and then never changed again?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nepomuk_fix.diff
Type: text/x-patch
Size: 1788 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130308/76112313/attachment-0001.diff>