[Nepomuk] High mutex contention in Nepomuk2::Resource

[Vishesh Handa]

On Fri, Mar 8, 2013 at 5:21 PM, David Faure <faure at kde.org> wrote:

> 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?
>

Ship it!


>
> 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.
>

Uhm. Okay.


>
> 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?
>

Yes. It's not always empty initially, sometimes it is provided in the
constructor. But it is never changed again.



> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
>


-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130308/3a7a891d/attachment.html>