[Development] QBasicMutex::lockInternal() race condition?

Tony Van Eerd tvaneerd at rim.com
Thu Sep 20 17:30:32 CEST 2012


I've been looking at the implementation of QMutex (et al), via woboq, ie http://code.woboq.org/qt5/qtbase/src/corelib/thread/qmutex.cpp.html.  (nice work on the code viewer, by the way!)

I'm wondering if there isn't a subtle race condition in lockInternal() at line 358:

358                 if (!d->ref())
359                     continue; //that QMutexData was already released

In the case where you pick up the d_ptr that was allocated by another thread - how do you know that d is still valid?

IIUC, d comes from the freelist, so it is probably never actually an invalid pointer, but how do you know that:

1 this mutex was locked by another thread
2 this mutex  was unlocked by that (or yet another) thread
3 the d_ptr was released
4 the released pointer was recycled into another mutex via the freelist
5 then line 358 runs.

ie d->ref() passes, but 'd' is for the wrong mutex?


By the way, as a bit of background about me:
- I work at RIM (as the email address probably notes), as a Senior Developer on BB10
- I've done a fair bit of lock-free work and research, see, for example, BoostCon talks (http://boostcon.boost.org , http://www.youtube.com/user/BoostCon/ )
(so I *think* I understand the code, but admit that I may have missed something, which is always easy in lockfree)

Tony

P.S. I've also taken a look at the interesting discussions and changes:

http://lists.qt-project.org/pipermail/development/2012-August/005832.html+ replies

http://www.mail-archive.com/development@qt-project.org/msg03875.html + replies

This is the change for QBasicMutex in Qt5

http://qt.gitorious.org/qt/qtbase/commit/b69bb01/diffs


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120920/d0530d4d/attachment.html>


More information about the Development mailing list