[Development] Thread-safety on implicitly-shared classes

Thiago Macieira thiago.macieira at intel.com
Sun Feb 5 17:30:56 CET 2012


Hi all

During the QJsonDocument review process, I pointed out a problem with using 
const_cast that I argued was a violation of the thread-safety rules. Lars 
disagreed, so we talked here at FOSDEM. Strict reading of the docs at
	http://developer.qt.nokia.com/doc/qt-4.8/threads-reentrancy.html
	http://developer.qt.nokia.com/doc/qt-4.8/threads-modules.html#threads-
and-implicitly-shared-classes

say that the implicitly-shared classes are *reentrant*, not thread-safe. That 
means no method at all must be called in objects being shared, like global 
objects or pointers to objects also used in other threads.

However, in practice, many people have begun relying on an implementation 
detail that read-only operations (the const methods) in those classes are 
thread-safe. That is, a shared object can be accessed without mutex protection 
provided only const functions are called.

That is not codified in the documentation.

I'd like to propose that it is and we say that all const methods in the 
implicitly-shared classes are thread-safe. It should also explain that calling 
a non-thread-safe method in the same object simultaneously with a thread-safe 
one breaks the safety (which is different to what "thread-safety" means to 
QCoreApplication::postEvent).

Note that there are a lot of implicitly-shared classes listed at 
http://developer.qt.nokia.com/doc/qt-4.8/implicit-sharing.html#shared-classes.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120205/a3d83830/attachment.sig>


More information about the Development mailing list