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

David Faure faure at kde.org
Thu Sep 6 16:40:09 UTC 2012

This is an automatically generated e-mail. To reply, visit:

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

Review request for Nepomuk, Vishesh Handa and Sebastian Trueg.


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.


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.

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/



David Faure

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

More information about the Nepomuk mailing list