[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)
On Mon, Feb 1, 2010 at 5:23 PM, Frank Mori Hess <frank.hess@nist.gov> wrote:
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 threads get the root from the global map - they'd get to read the very same shared_ptr variable; If two threads happen to walk the same node and try to get the "father" - they'd get to "lock" on the same weak_ptr variable simultaneously. Is that a problem? (assuming that I have "read locks" in place - i.e. there is currently no "writer" thread that is trying to completely remove a tree from the global map) [BTW - that's the only way that "writing" ever occurs: a "writer thread" builds an alternate version of a tree, and then acquires a write lock and replaces the old tree in the global map; there may be still walker threads that walk the "old tree" - but that should be ok since they keep a copy of the shared_ptr, basically guaranteeing that the old tree itself is not destroyed as long as there is a walker on it ]