From: David Maisonave (boost_at_[hidden])
Date: 2006-01-31 05:09:17
"David Abrahams" <dave_at_[hidden]> wrote in message
news:<8764o1azuq.fsf_at_[hidden]>...
> "David Maisonave" <dmaisonave_at_[hidden]> writes:
> >> IIUC, the thread-safety problem with reference-linked
> >> implementation
> >> isn't that so much that it's hard to achieve -- anyone can use a
> >> shared mutex -- it's that it's hard to make a thread-safe
> >> implementation efficient. That is to say, you pay for the cost of
> >> locking and unlocking a mutex, and there's no way around it (**).
> >> Locking and unlocking mutexes is way more expensive than performing
> >> the lock-free operations used by boost::shared_ptr.
> >
> > That's true. But it's been my experience that the majority of
> > development don't have objects access via multiplethreads or don't
> > run in a multithread environment. In this environment, you're paying
> > additional price for using boost::shared_ptr reference-count logic,
> > but not getting any benefits from it.
>
> Not if you're compiling without mt support on; the thread safety
> features of shared_ptr just compile away (and I think there's a macro
> you can use to force them off). Let's compare apples to apples: your
> reflinked implementation will be slower in a MT environment. I'm not
> yet convinced it will be faster in a ST environment unless you leave
> the MT features of shared_ptr turned on.
Currently, my test results don't support your above comment.
Please provide the this macro you're referring to.
Without this macro, there's no way of testing your claim.