[Nepomuk] Review Request: Fix race conditions in nepomuk's ResourceData.

[David Faure]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105562/
-----------------------------------------------------------

(Updated Sept. 6, 2012, 4:40 p.m.)


Review request for Nepomuk, Vishesh Handa and Sebastian Trueg.


Changes
-------

Completely reworked the fix, so that the RM mutex is held before calling determineUri, and so that no AB/BA deadlocks happen: the rule is that the RM mutex must never be locked after the modificationMutex.
It's either modification alone, or RM and then modification.

I had to move some code from RM to RD, because RM was using data->m_cache directly, without locking data's mutex first!
This new code is not only more threadsafe (no helgrind warning anymore in my tests) but also much better object-oriented, RM is no longer accessing RD's private data directly.


Description
-------

Fix race conditions in nepomuk's ResourceData.

Found with "helgrind kmail --nofork", inbox, clicking on any email.
where helgrind is "QT_NO_GLIB=1 valgrind --tool=helgrind --track-lockorders=no"

The change in resource.cpp avoids a deadlock due to the change
in resourcedata: no need to hold the rmMutex for the determineUri call.


This addresses bug 295802.
    http://bugs.kde.org/show_bug.cgi?id=295802


Diffs (updated)
-----

  libnepomukcore/resource/resourcedata.h 7e185a7 
  libnepomukcore/resource/resourcedata.cpp c14582f 
  libnepomukcore/resource/resourcemanager.cpp 2a6668a 

Diff: http://git.reviewboard.kde.org/r/105562/diff/


Testing
-------


Thanks,

David Faure

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120906/a68411fb/attachment.html>