On 2/5/12 5:30 PM, "ext Thiago Macieira" <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
