[Development] Thread-safety on implicitly-shared classes

lars.knoll at nokia.com lars.knoll at nokia.com
Sun Feb 5 18:10:55 CET 2012

On 2/5/12 5:30 PM, "ext Thiago Macieira" <thiago.macieira at intel.com> wrote:

>Hi all
>During the QJsonDocument review process, I pointed out a problem with
>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-
>say that the implicitly-shared classes are *reentrant*, not thread-safe.
>means no method at all must be called in objects being shared, like
>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
>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
>a non-thread-safe method in the same object simultaneously with a
>one breaks the safety (which is different to what "thread-safety" means

I'm happy with changing this (I actually think it's a good idea), but
wanted to have this brought to the ML before deciding on it, as it has
implications on how you implement implicitly shared classes.

>Note that there are a lot of implicitly-shared classes listed at

Yes, so we can either go through and clean them all up at once (best,
since it might require API changes as with QString::utf16()), or introduce
a new name for this kind of thread safety and document which classes work
that way.

I'd prefer the first one, but it's a matter of resources, as we'll have to
go through quite some code.


More information about the Development mailing list