Am Friday 04 September 2009 18:17:36 schrieb Chris Uzdavinis:
the shared_ptr doc says that you can expect the same thread safety from shared_ptr as you can from built-in types.
This is true, but you're drawing the wrong conclusion from it. You need a lock around built-in types as well. You need to use an "atomic" type to safely do what you're saying.
In the same documentation, they give examples which are enlightening:
//--- Example 3 ---
// thread A p = p3; // reads p3, writes p
// thread B p3.reset(); // writes p3; undefined, simultaneous read/write
I believe this means that the contents of p are undefined, not that there is an undefined state within a shared_ptr (on a platform that guarantees atomic pointers)
you can use multiple-readers-single-writer without any locks on built-in types.
Not true. You can use multiple-readers, NO-writers without any locks, however.
you can on platforms with atomic builtin types, as the c++ standard doesn't say anything about that (yet). so if it is really true that that's not the case for shared_ptr, then the statement of the shared_ptr doc would be wrong. but as far as I can see from the shared_ptr implementation there is nothing that would indicate that. could someone with more insight into the implementation clear this up please? (and maybe the documentation)