[Nepomuk] High mutex contention in Nepomuk2::Resource

[Simeon Bird]

Hi,

I read through the patches - 0002, 0004 and 0005 are good. For 0001,
can you not instead of this:

    lock.unlock();
    QMutexLocker rmlock(&m_rm->mutex); // for updateKickOffLists, but
must be locked first
    lock.relock(); // we must respect the lock ordering!

     const QString newNaoIdentifier =
m_cache.value(NAO::identifier()).toString();
     const QUrl newNieUrl = m_cache.value(NIE::url()).toUrl();
     updateIdentifierLists( oldNaoIdentifier, newNaoIdentifier );

do this:

     const QString newNaoIdentifier =
m_cache.value(NAO::identifier()).toString();
     const QUrl newNieUrl = m_cache.value(NIE::url()).toUrl();

    lock.unlock();
    QMutexLocker rmlock(&m_rm->mutex); // for updateKickOffLists, but
must be locked first

     updateIdentifierLists( oldNaoIdentifier, newNaoIdentifier );

No rule says you can't take the mutexes independently, only that if
you take them both you must take the rmmutex first, no?

For patch 3, how about the attached two patches instead?

I pushed a feature branch: feature/resourcemanagercleanup with both
these patch series in them. It's on top of KDE/4.10, and your patches
are on top of mine. Does it make sense to you? Vishesh, what do you
think?

Thanks
Simeon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Make-the-initMutex-a-ReadWriteLock-so-multiple-threa.patch
Type: application/octet-stream
Size: 4396 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130314/6833e518/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ResourceManager-ResourceWatcher-Make-removeResource-.patch
Type: application/octet-stream
Size: 5202 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130314/6833e518/attachment-0001.obj>