[Development] Thread-safety on implicitly-shared classes

[lars.knoll at nokia.com]

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
>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).

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
>http://developer.qt.nokia.com/doc/qt-4.8/implicit-sharing.html#shared-clas
>ses.

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.

Cheers,
Lars