Am Friday 04 September 2009 20:42:48 schrieb John Dlugosz:
I agree that "just like built-in types" would not hold for the nonstandard implementation behavior of atomic reads and writes, so many people might misunderstand that.
I've had to implement smart-pointer like things that do have this feature, so it must be carefully designed to have only a single pointer in the main struct and update things to maintain a valid state at all times (e.g. swap in that main pointer last). I don't suppose a standard-conforming shared_ptr would have that feature unless explicitly advertised as such.
can you point to anything that the boost shared_ptr does that is unsafe in the one-writer-multiple-reader case? TR1 doesn't mention thread safety or atomicity at all, so strictly speaking the guarantee that the boost shared_ptr doc gives is already an extension. writing to an expired weak_ptr while multiple readers are trying to lock() it seems safe to me. (in the current implementation)