Re: [Boost-users] boost::weak_ptr usage in multithreaded environments

Subject: Re: [Boost-users] boost::weak_ptr usage in multithreaded environments
From: Virgil Palanciuc (virgilp_at_[hidden])
Date: 2010-02-01 10:58:24

>> [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_at_[hidden]> 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 ]