[Nepomuk] High mutex contention in Nepomuk2::Resource

[David Faure]

On Friday 08 March 2013 17:43:51 Vishesh Handa wrote:
> 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!

Thanks, done.
(Do I need to cherry-pick into master or will a future git merge grab it?)

I now noticed that the kmail main thread still waits for the ResourceManager mutex in another case:

KMail::TagActionManager::updateActionStates calls

 97├>Nepomuk2::Resource::Resource( const QUrl& uri, const QUrl& type )
 98│ {
 99│     ResourceManager* rm = ResourceManager::instance();
100│     if( rm ) {
101│         QMutexLocker lock( &rm->d->mutex );
102│         m_data = rm->d->data( uri, type );
103│         if ( m_data )
104│             m_data->ref( this );
105│     }
106│     else {
107│         kError() << "QCoreApplication does not exist. Resource cannot be initalialized";
108│     }

(see line 101).

Not sure we can do much about that though. Except finding out why that mutex is locked for so long, but the answer is always "because another thread is waiting for an answer in Soprano code". Example:

#3  0x00007fc123d3299d in Soprano::Client::ClientModel::executeQuery (this=0x13c39b0, query="select distinct ?r ?o where { { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#url> <akonadi:?item=1209870> . FILTER(?r!=<akonadi:?item=1209870>) . } UNION { <akonadi:?item=1209870> ?p ?"..., language=Soprano::Query::QueryLanguageSparql, userQueryLanguage="") at /d/kde/src/4/kdesupport/soprano/client/clientmodel.cpp:101

#4  0x00007fc1332a504a in Nepomuk2::MainModel::executeQuery (this=0x1366b80, query="select distinct ?r ?o where { { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#url> <akonadi:?item=1209870> . FILTER(?r!=<akonadi:?item=1209870>) . } UNION { <akonadi:?item=1209870> ?p ?"..., language=Soprano::Query::QueryLanguageSparql, userQueryLanguage="") at /d/kde/src/4/kde/kdelibs/nepomuk-core/libnepomukcore/resource/nepomukmainmodel.cpp:183

which means the problem is in another process, either nepomukstorage or virtuoso, right?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5