Threads and Implicit Sharing

[wysota]

You can read the contents from two threads without safeguards. But you can't read from one thread and write from another thread without a mutex.

[stillwaiting]

You can read the contents from two threads without safeguards. But you can't read from one thread and write from another thread without a mutex.

Hi wysota, thank you for your reply. I'm wondering if such behavior is described somewhere in the documentation? The only information I've found about threads and implicit sharing is : http://doc.qt.nokia.com/qtopia4.2/th...plicit-sharing , but it says nothing about readonly access from different threads. Just for comparison: this is what the documentation says about the same issue for containers:

"The container classes are implicitly shared, they are reentrant, and they are optimized for speed, low memory consumption, and minimal inline code expansion, resulting in smaller executables. In addition, they are thread-safe in situations where they are used as read-only containers by all threads used to access them."

[wysota]

Hi wysota, thank you for your reply. I'm wondering if such behavior is described somewhere in the documentation

No, it is purely based on knowledge how this is implemented and knowledge what access from different threads can break in an object (any object). Using const methods of an object (any object) from different threads is always safe unless some members of a class are declared as mutable. This is also the case for implicitly shared classes. The only doubtful situation is when an implicitly shared object is copied but since this only happens when an object is modified (hence not from within a const method), the object is safe for read-only access from different threads. Note, you have to make sure no member of the class (or its private implementation) is mutable. Should an internal representation of the class be changed to introduce a mutable non-atomic member, your existing code might stop working.

[stillwaiting]

Should an internal representation of the class be changed to introduce a mutable non-atomic member, your existing code might stop working.

But... how can I be sure that mutable parameters will not appear in QString's (or others' implicitly shared Qt4 classes) implementation in future versions of Qt?

[wysota]

how can I be sure that mutable parameters will not appear in QString's (or others' implicitly shared Qt4 classes) implementation in future versions of Qt?

You can't be sure but in general if they appeared, it would break the implicit sharing functionality as well so it's highly unlikely to happen.
You also can't guarantee some developer that uses your code will not try to cast away constness from an item and call non-const methods on the const object. But all this is not related to implcitly-shared classes, it all applies to any reentrant class. Implicit sharing itself does not impose any limitations regarding this issue.