Re: [boost] Re: [shared_ptr] Interlocked* - possible bug?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-09-30 11:07:11

Alexander Terekhov wrote:
> Peter Dimov wrote:
> [...]
>> bool expired()
>> {
>>     return !lock();
>> }
>>
>> I don't think that this is an improvement. The user that wants
>> !lock() writes !lock(). The user that wants a (potentially more
>> efficient version of - insert "in theory" here as well) use_count()
>> == 0 writes expired().
>                                        ^^^^^^^^^^^
>
> Well, I'm a bit puzzled by its "unspecified nonnegative value" and
> "number of shared_ptr objects" (if you allow counting of null owners)
> bits, to tell the truth.

Yeah.

http://boost.org/libs/smart_ptr/weak_ptr.htm#use_count

is a bit out of date, "the" specification is at

http://open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html

and in the TR. I'll fix the boost documentation when I rewrite the pointers 
to use atomics.

"Returns: 0 if *this is empty; otherwise, the number of shared_ptr instances 
that share ownership  with *this."

>> It is deliberately "unspecified" whether expired() msyncs or not.
>
>  long use_count() const {
>    shared_ptr<T> const & p = lock();
>    return p ? p.use_count() - 1 : 0;
>  }
>
> Oder? ;-)

An implementation can do that if it wants to, but I don't want to impose it 
as a requirement. It's better to allow use_count() to lag behind in MT code 
for performance reasons, because idiomatic weak_ptr use does not rely on the 
latest value anyway.

>>> It's PDQ in practice (unless you have a
>>> compiler smart enough to ignore volatile hack and use a cached
>>> copy in spite of it because you're not supposed to noticed the
>>> difference according to the MT memory model rules).
>>
>> You need to insert lots of "in theory" here.
>>
>> * "volatile" is specifically intended to prevent "smartness".
>
> Your use of a volatile variable is indistinguishable (no change
> in behavior whatsoever) from a non-volatile variable if/when run
> single-thread.

No, it's not; C++ behavior _is defined in terms of_ volatile (and I/O 
calls), not the other way around.