[long story short: I'd like to know whether a weak_ptr.lock() counts as a "shared pointer read" or as a "shared pointer write" ]
It is a "const" member function and counts as a read. Yeah, it's const allright... which means it doesn't modify the underlying weak_ptr<> object, not that it doesn't modify the shared "shared_ptr" counter. To me, it feels that it should count as a "read" (since it's allowed to "copy" the same shared_ptr from two threads simultaneously, it *should* be allowed to create copies from weak_ptrs, too - but I thought I should double-check).
Would it be possible to extract a simplified example in which the crashes still occur? Don't think so :(, it's extremely hard to reproduce, currently it only (sort of) reproduces in Snow Leopard.. and probably would no longer reproduce if I'd trim the "application" from around it (assuming that it would be feasible, at all, to trim the rest of the app)
Creating and destroying shared_ptr (including those created through weak_ptr::lock) doesn't require any locking at all, as far as the reference counting goes. Unless you are trying to simultaneously access the same weak_ptr/shared_ptr object (rather than copies pointing at the same thing) from different threads? What if I were accessing the very same shared_ptr/weak_ptr object from different threads? Is this problematic (i.e. "read access", not "read/write")? As I said, I have a global map that keeps the "tree roots"(as shared_ptr), and potentially many "walkers" that walk the tree. If two
On Mon, Feb 1, 2010 at 5:23 PM, Frank Mori Hess