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

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-09-30 14:24:58

Peter Dimov <pdimov_at_[hidden]> wrote:
> Ben Hutchings wrote:
<snip>
> > I feel the naming of functions may give a false sense of generality
> > and encapsulation when they actually only work in the way they are
> > being used currently.
> 
> I'm not sure which functions do you have in mind here.

I'm perhaps overstating the case, but still:

Firstly, atomic_read.  I think people generally expect atomicity and
ordering to go hand-in-hand - though I realise they don't have to - and
the other functions whose names begin with "atomic_" do prevent
reordering of their memory accesses, so this name could be misleading.

Secondly, use_count's return values can only be used in very specific
ways (e.g. the comparison with 0 as an optimisation in
weak_ptr<>::lock).  I realise that the use_count functions in
shared_ptr and weak_ptr are documented as "only for debugging and
testing purposes", but I was kind of thinking the name ought to suggest
that.  (Also the documentation fails to point out that return values
can immediately become incorrect in multithreading systems, and has
postconditions based on use_count() that won't necessarily be true if
tested in real code, though this perhaps ought to be obvious.)

> http://66.102.9.104/search?q=cache:1ZQ1uXtFUEIJ:www.pdimov.com/cpp/
> shared_count_x86_exp2.hpp

Thanks for that.